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1.0  INTRODUCTION 


This  document  is  the  final  report  summarizing  the  work 
performed  by  Delta  Information  Systems,  Inc.  for  the  Office  of 
Technology  and  Standards  of  the  National  Communications  System 
under  Purchase  Order  No.  DCA100- 80-M-0200.  The  Office  of 
Technology  and  Standards,  headed  by  National  Communications’ 
System  Assistant  Manager  Marshall  L.  Cain,  is  responsible  for 
the  management  of  the  Federal  Telecommunications  Standards  Pro¬ 
gram,  which  develops  telecommunication  standards  whose  use  is 
mandatory  by  all  Federal  agencies. 

The  CCITT  (International  Telegraph  and  Telephone  Consulta¬ 
tive  Committee)  has  classified  all  facsimile  systems  into  four 
categories  or  Groups  in  accordance  with  the  parameters  listed  in 
Table  1-1.  Groups  1  and  2  employ  analog  transmission  and  trans¬ 
mit  a  page  in  a  fixed  period  of  time.  The  vast  majority  of  fac¬ 
simile  units  in  the  field  today  conform  to  Groups  1  and  2.  In 
Group  3  the  page  is  digitally  transmitted  over  the  switched 
telephone  network.  Compression  techniques  are  employed  to- re¬ 
duce  the  transmission  time.  The  recommended  standards  for 
Group  3  were  recently  finalized  by  the  CCITT. 

According  to  the  CCITT  definition.  Group  4  facsimile  ap¬ 
paratus  "incorporates  means  for  reducing  the  redundant  informa¬ 
tion  in  the  document  signal  prior  to  transmission,  mainly  via 
Public  Data  Networks  (PDN) .  The  apparatus  will  utilize  pro¬ 
cedures  applicable  to  the  PDN  and  will  assume  error-free  recep¬ 
tion  of  the  document.  The  apparatus  may  also  be  used  on  the 
public  telephone  network  where  an  appropriate  modulation  process 
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will  be  utilized.”  The  process  of  standardization  for  Group  4 
is  in  its  very  early  formative  stages.  The  purpose  of  this 
study  is  to  anticipate  and  support  this  standardization  effort 
to  insure  that  future  facsimile  systems  will  be  available  to  the 
U.S.  Government  having  a  high  level  of  reliability,  inter¬ 
operability,  and  overall  performance.  Specifically  the  purpose 
of  the  study  is  to  identify  those  facsimile  parameters  requir¬ 
ing  standardization,  and  the  analysis  of  these  parameters  to 
determine  likely  trends  and  options. 

To  provide  a  general  background  for  the  standardization 
study.  Section  2.0  reviews  the  general  nature  of  data  networks 
with  particular  emphasis  on  Public  packet  switched  networks. 
Section  3.0  examines  the  generic  structure  of  a  Group  4  fac¬ 
simile  system  and  identifies  those  parameters  which  require 
standardization,  and  those  which  do  not.  There  are  four  major 
characteristics  of  the  Group  4  system  which  must  be  standard¬ 
ized-  -resolution,  compression  technique,  data  rates,  and  com¬ 
munications  protocol.  Each  of  these  parameters  is  analyzed 
independently  in  Sections  4.0,  5.0,  6.0,  and  7.0  respectively. 
Section  8.0  contains  a  summary  and  conclusion  of  the  investi¬ 
gation.  Finally,  recommendations  for  further  study  are  included 
in  Section  9.0. 

Delta  Information  Systems  is  greatly  indebted  to  those 
members  of  the  facsimile  and  packet  switching  communities  who 
contributed  information  to  this  report.  We  also  acknowledge  the 
support  and  guidance  of  Dennis  I’olsaiw,'  the  Contractor's  Tech¬ 
nical  Representative  from  the  National  Communications  System. 
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2.0  DATA  NETWORKS 


A  large  demand  for  data  communications  has  stemmed  from  com¬ 
puter  users  accessing  remote  computers  via  the  switched  telephone 
network. 

Typically,  a  user  would  dial  the  computer  over  a  switched 
phone  circuit  which  would  be  tied  up  for  the  entire  period  of  the 
data  "conversation."  The  data  interchange  between  the  computer 
and  user  terminal  is  usually  very  bursty.  Consequently  the  cost 
of  the  voice  circuit  is  excessive  relative  to  the  typical  amount 
of  data  interchanged.  In  addition,  when  the  telephone  network 
employs  conventional  modems  for  digital  communications,  a  rela¬ 
tively  large  number  of  transmission  errors  frequently  occur. 

Data  networks  have  been  developed  during  the  1970 's  to  attack 
these  two  critical  problems  which  have  plagued  computer  communi¬ 
cations-  -excessive  communication  cost  and  excessive  transmission 
errors.  Consequently  the  two  most  distinguishing  characteristics 
of  the  new  data  networks  are  1)  the  efficient  use  of  the  communi¬ 
cations  resource  by  sophisticated  switching,  routing,  and  multi¬ 
plexing  techniques,  and  2)  the  virtual  elimination  of  end-to-end 
errors  by  error-control  procedures. 

Table  2-1  is  a  summary  of  some  of  the  key  characteristics 
of  public  data  networks.  Note  that  one  way  of  describing  a  net¬ 
work  is  by  the  type  of  switching  employed.  In  the  case  of  store- 
and-forward  message  switching  (e.g.  Graphnet,  Telex  and  Autodin) 
the  entire  message  is  transmitted  sequentially  through  the  net¬ 
work  from  node  to  node.  In  this  way  the  entire  message  is  received 
and  stored  at  a  node  before  being  relayed  to  the  next  node.  The 


thruput  of  such  a  system  becomes  severely  limited  as  the  traffic 
level  increases  and  as  the  raw  channel  error  rate  increases. 
Packet  switched  networks  have  been  developed  to  achieve  a  higher 
level  of  throughput  and  responsiveness  to  the  user  when  compared 
to  message  switching  networks.  In  a  packet  switched  network  the 
information  to  be  transmitted  is  divided  into  packets,  where  a 
typical  packet  may  contain  1,024  bits.  By  reducing  the  size  of 
this  basic  transmitted  unit  of  information  from  the  entire  mes¬ 
sage  to  a  small  packet,  the  thruput  of  the  network  is  greatly  in¬ 
creased. 

By  employing  sophisticated  switching,  multiplexing,  and 
storage  techniques  at  the  network  nodes,  the  data  links  which 
interconnect  the  nodes  are  utilized  with  a  very  high  level  of 
efficiency.  In  this  way  the  communication  costs  have  been  sig¬ 
nificantly  reduced.  For  example:  the  basic  cost  element  for 
Telenet  is  50$  per  kilopacket;  and  the  basic  rate  for  Tymnet  is 
34  per  kilocharacter .  Other  advantages  and  characteristics  of 
the  data  networks  are  listed  below. 

-Transmission  charges  are  independent  of  distance. 

-Terminals  having  several  optional  bit  rates  may  be  con¬ 
nected  to  the  network.  The  network  will  automatically 
adapt  to  the  particular  appropriate  data  rate  which 
the  user  has  selected. 

-The  user  pays  only  for  the  data  which  was  transmitted. 

-Some  networks  (e.g.  Telenet)  have  a  multipoint  broadcast 
capability.  The  user  feeds  the  network  only  one  mes¬ 
sage  along  with  a  list  of  addresses. 
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At  this  point  it  is  useful  to  define  several  of  the  key  terms 
which  are  related  to  data  networks.* 

Packet :  A  packet  of  information  is  a  finite  sequence  of 
bits,  divided  into  a  control  header  part  and  a  data  part.  The 
header  will  contain  enough  information  for  the  packet  to  be  routed 
to  its  destination.  There  will  usually  be  some  checks  on  each 
such  packet,  so  that  any  switch  through  which  the  packet  passes 
may  exercise  error  control.  Packets  are  generally  associated  with 
internal  packet-network  operation  and  are  not  necessarily  visible 
to  host  computers  attached  to  the  network. 

Datagram:  A  finite  length  packet  of  data  together  with  des¬ 
tination  host  address  information  (and,  usually,  source  address) 
which  can  be  exchanged  in  its  entirety  between  hosts,  independent 
of  all  other  datagrams  sent  through  a  packet  switched  network. 
Typically,  the  maximum  length  of  a  datagram  lies  between  1000  and 
8000  bits. 

Gateway :  The  collection  of  hardware  and  software  required 

to  effect  the  interconnection  of  two  or  more  data  networks,  enabling 
the  passage  of  user  data  from  one  to  another. 

Host :  The  collection  of  hardware  and  software  which  utilizes 
the  basic  packet  -  switching  service  to  support  end-to-end  inter¬ 
process  communication  and  user  services. 

Packet  Switch:  The  collection  of  hardware  and  software  re¬ 
sources  which  implements  all  intranetwork  procedures  such  as  rout¬ 
ing,  resource  allocation,  and  error  control  and  provides  access  to 
network  packet-switching  services  through  a  host/network  interface. 

Protocol :  A  set  of  communication  conventions,  including 
formats  and  procedures  which  allow  two  or  more  end  points  to  com- 
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municate.  The  end  points  may  be  packet  switches,  hosts,  terminals, 
people,  file  systems,  etc. 

Protocol  Translator:  A  collection  of  software,  and  possibly 
hardware,  required  to  convert  the  high  level  protocols  used  in  one 
network  to  those  used  in  another. 

Terminal :  A  collection  of  hardware*  and  possibly  software  , 
which  may  be  as  simple  as  a  character-mode  teletype  or  as  complex 
as  a  full  scale  computer  system.  As  terminals  increase  in  capa¬ 
bility,  the  distinction  between  "host"  and  ’’terminal"  may  become 
a  matter  of  nomenclature  without  technical  substance. 

Virtual  Circuit:  A  logical  channel  between  source  and  des¬ 
tination  packet  switches  in  a  packet -switched  network.  A  virtual 
circuit  requires  some  form  of  "setup"  which  may  or  may  not  be 
visible  to  the  subscriber.  Packets  sent  on  a  virtual  circuit  are 
delivered  in  the  order  sent,  but  with  varying  delay. 

PTT:  Technically  PTT  stands  for  Post,  Telegraph,  and  Tele¬ 
phone  Authority;  this  authority  has  a  different  form  in  different 
countries.  In  this  paper,  by  PTT  we  mean  merely  the  authority 
(or  authorities)  licensed  in  each  country  to  offer  public  data 
transmission  services. 

One  of  the  most  critical  issues  in  the  development  of  data 
networks  is  the  standardization  of  the  interface  between  the  data 
network  and  user  systems  such  as  data  terminals  and  host  computers. 
The  International  Telegraph  and  Telephone  Consultative  Committee 
(CCITT)  has  led  the  way  in  this  standardization  process.  In  1976 
the  CCITT  approved  Recommendation  X.2S  which  is  entitled  "Inter¬ 
face  between  Data  Terminal  Equipment  (DTE)  and  Data  Circuit - 
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Terminating  Equipment  (DCE)  for  terminals  operating  in  the  packet 
mode  on  Public  Data  Networks."  A  copy  of  the  recently  revised 
version  of  this  recommendation  is  included  in  Appendix  A. 

Figure  2-1  is  a  block  diagram  which  illustrates  the  three  archi¬ 
tectural  levels  of  the  X.25  interface  standard. 

-Level  1  -  Physical  level:  The  mechanical,  electrical, 
functional  and  procedural  characteristics  to  activate, 
maintain  and  de- activate  the  physical  link  between  the 
DTE  and  the  DCE.  The  X.25  standard  recommends  the  use 
of  X.21  for  the  physical  level  standard.  EIA  Standards 
RS232C  and  RS449  are  also  physical  level  standards  which 
are  applicable. 

-Level  2  -  Link  level:  The  link  access  procedure  for  re¬ 
liable  data  interchange  across  the  link  between  the  DTE 
and  the  data  network;  error  handling,  flow  control;  e.g. 
"rcvr  ready,"  "rcvr  not  ready."  The  X.25  standard  recom¬ 
mends  the  use  of  the  HDLC/LAPB  standard  proposed  by  ISO. 

-Level  3  -  Network/Packet  level:  Defines  the  packet  for¬ 
mats  and  control  prcoedures;  controls  the  addressing, 
switching,  and  routing  of  the  information  to  establish 
a  virtual  circuit  connection  through  the  network. 

Table  1  points  out  that  most  of  the  major  data  networks  pro¬ 
vide  an  X.25  interconnect  capability  at  the  present  time.  Since 
the  X.25  interface  is  generally  recognized  as  the  primary  standard 
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for  the  data  network  interconnection,  it  is  anticipated  that  this 
standard  will  be  selected  for  Group  4  facsimile.  Section  7.0  of 
this  report  discusses  X.2S  in  more  detail  along  with  the  higher 
levels  of  interconnect  architecture. 

The  reader  will  note  in  Figure  2-1  that  the  Group  4  facsimile 
terminal  may  be  viewed  as  any  other  user's  data  terminal  connected 
to  a  data  network.  Section  2.0  looks  at  the  general  nature  of  a 
digital  facsimile  system  from  a  Group  4  perspective. 


3.0  GENERAL  DISCUSSION  OF  GROUP  4  FACSIMILE 


Figure  3-1  is  a  functional  block  diagram  illustrating  the 
general  organization  of  Group  4  facsimile  scanners/printers  and 
how  they  may  relate  to  data  networks  and  remote  computer  systems. 

The  key  characteristic  of  the  scanner  and  printer  elements  of  the 
facsimile  units  is  their  resolution.  This  parameter  is  discussed 
in  detail  in  Section  4.0  and  will  not  be  reviewed  here.  Similarly 
the  compressor /decompressor,  communications  interface,  and  data 
rates  are  handled  in  Sections  5.0,  6.0,  and  7.0  respectively. 

The  remaining  elements- -pre-processing,  post-processing,  storage, 
and  computer  application  processes  are  discussed  below  in  Sec¬ 
tions  3.1  through  3.4. 

3.1  Pre-Processing 

One  fundamental  pre-process  which  must  be  performed  in  all  digital 
facsimile  systems  is  the  threshold  operation  where  the  analog 
video  output  from  the  scanner  is  sampled  and  converted  to  a  bi¬ 
nary,  black-white  signal. 

This  threshold  operation  can  vary  widely  in  complexity  from 
a  simple  fixed- level  slicing  circuit  to  a  sophisticated  unit 
which  dynamically  senses  the  document  background  level  and  adap¬ 
tively  controls  the  threshold  level  relative  to  that  background. 

Since  there  is  no  need  to  standardize  this  process,  it  will  not 
be  discussed  further  in  this  report. 

Figure  3-2  illustrates  how  digital  facsimile  systems  generate 
an  inherent  spatial  noise  pattern  which  has  two  disadvantages: 

1)  the  output  image  appears  noisy;  2)  a  reduction  in  the  compres- 
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sion  ratio.  Spatial  noise  filters  such  as  that  illustrated  in 
Figure  3-3  may  be  employed  to  reduce  this  distortion.  This  pro¬ 
cess,  like  the  threshold  operation,  need  not  be  standardized  to 
achieve  compatibility.  Hence  it  will  not  be  treated  further  in 
this  report. 

3.2  Post -Processing 

In  some  instances  there  are  advantages  to  performing  a  post¬ 
processing  operation  at  the  facsimile  receiver  just  prior  to 
printing.,  In, a  process  could  have  several  possible  functions, 
two  of  which  are  listed  below: 

-Error  processing  --  It  is  not  difficult  for  a  facsimile 
receiver  to  sense  when  a  transmission  error  has  occurred 
in  a  particular  scan  line.  It  is  then  possible  to  process 
the  received  data  in  such  a  manner  as  to  minimize  the  sub¬ 
jective  effect  of  that  error. 

-Interpolation  --  One  may  consider  the  general  case  where 
the  resolution  of  the  printer  is  greater  than  that  of  the 
scanner.  In  this  situation  it  would  be  possible  to 
"interpolate"  the  likely  colors  of  those  printed  pels 
which  were  not  transmitted.  An  intelligent  interpolator 
will  usually  be  correct  in  its  estimate. 

Post-processing,  like  pre-processing  is  not  an  important 
parameter  to  be  standardized  since  it  need  not  be  specified  to 
achieve  interoperability.  Therefore  it  will  not  be  discussed 
further  in  this  report. 


3.3  Storage 

The  Group  4  facsimile  scanner  and  printer  units  must  store 
a  minimal  amount  of  compressed  data  to  accommodate  the  uncertain¬ 
ties  of  the  error  control  system  in  the  data  network  and  terminal/ 
network  interface  link.  It  is  useful  to  consider  two  extreme 
example  of  Group  4  facsimile  terminals.  The  first  operates  at  a 
relatively  slow  speed  (e.g.  many  seconds  per  page)  such  that,  if 
the  network  has  problems,  the  paper  transport  in  the  scanner  or 
printer  can  be  slowed/stopped  until  the  network  recovers. 

On  the  other  hand  it  is  likely  that  some  future  Group  4 
facsimile  systems  will  be  developed  which  will  operate  at  suffi¬ 
ciently  high  speed  (e.g.  one  page  per  second)  that  the  document 
transport  cannot  be  stopped/slowed  within  a  document  cycle.  In 
this  case  it  is  likely  that  digital  storage  must  be  provided  for 
at  least  one  complete  page.  In  either  case  the  communication 
takes  the  form  of  a  memory- to -memory  transfer.  If  one  page,  or 
less,,  is  stored  it  is  possible  that  a  solid  state  memory  could  be 
utilized.  If  several  pages  are  to  be  stored  it  is  likely  that  a 
magnetic  media  would  be  used,  e.g.  hard  or  floppy  disc. 

3.4  Computer  Applications 

There  are  two  general  application  areas  for  Group  4  facsimile. 
The  first  is  the  conventional  scanner- to-printer  transmission  as 
is  most  commonly  accomplished  in  facsimile  today.  The  second  ap¬ 
plication  is  a  relatively  new  one.  It  considers  the  use  of  a 
facsimile  terminal  as  an  input/output  device  for  a  remote  com¬ 
puter.  It  is  true  that  there  is  some  limited  degree  of  facsimile/ 


3-6 


computer  interactions  today- -e.g.  Graphnet.  However  it  is  anti¬ 
cipated  that  the  development  of  Group  4  facsimile  will  usher  in 
a  totally  new  era  in  the  facsimile  business.  A  few  of  the  poten 
tial  computer  applications  are  described  below. 

-Electronic  Mail  -  A  large  fraction  of  business  mail  could 
be  potentially  exchanged  via  the  Public  Data  Network  using 
Group  4  facsimile  terminals. 

-Storage/Retrieval  from  linage  Data  Base  -  Large  quantities 
of  documents  could  be  stored  in  computer  form  so  they 
could  readily  be  printed  on  a  remote  facsimile  printer. 
This  is  an  example  of  what  has  been  called  the  remote 
copier  application. 

-Format  Conversion  -  It  is  likely  that  Group  4  facsimile 
units  will  be  compatible  with  a  wide  range  of  other  fac¬ 
simile  standards.  In  those  instances  where  two  image 
communication  devices  were  incompatible,  an  intermediate 
computer  process  could  effect  an  exchange  of  information. 

-Integration  of  Text  with  Graphics  -  Graphic  data  could 
be  scanned  by  a  Group  4  scanner  and  fed  to  a  graphics/ 
word  processing  system.  CRT  operators  would  view  the 
scanned  graphic  data  and  add  textual  data.  The  combined 
text/graphic  data  could  then  be  stored  and  distributed  to 
Group  4  printers. 

-OCR/ Analysis  of  Graphic  Data  -  Raw  symbol/character  data 
could  be  scanned  by  a  Group  4  facsimile  device  and  sent 
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to  a  computer  system  where  a  pattern  recognition  function  could 
be  performed. 
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4.0  RESOLUTION 


The  resolution  of  the  Group  4  facsimile  system  is  one  of 
the  most  important  parameters  to  be  standardized  because  it  is 
the  primary  factor  affecting  the  quality  of  the  output  page  as 
well  as  the  number  of  bits  required  for  transmission. 

For  reasons  of  compatibility  it  is  logical  to  first  con¬ 
sider  the  adoption  of  the  Group  3  resolution  standards  for 
Group  4. 

Group  3  Resolution 

The  horizontal  resolution  for  Group  3  equipment  is  fixed  at 
7.7  samples/mm  (nominally  200  samp les /inch) .  The  Group  3  verti¬ 
cal  resolution  has  been  standardized  at  3.85  lines/mm  (nominally 
100  li~**«/mch)  with  an  option  at  7.7  lines/mm.  It  is  likely  that 
these  two  resolution  standards  will  be  included  in  the  Group  4 
standard.  The  reasons  are  twofold.  First,  these  resolutions 
have  been  found  to  be  adequate  for  a  wide  range  of  applications 
many  of  which  will  persist  in  the  Group  4  environment.  Second, 
it  is  advantageous  for  Group  4  systems  to  be  downward  compatible 
with  Group  3. 

Higher  Resolution 

There  is  some  consideration  in  the  facsimile  community  of 
adding  a  third  Group  4  resolution  option  which  would  be  higher 
than  200  lines/inch.  The  primary  rationale  for  such  a  standard 
is  that  the  human  observer, without  benefit  of  optical  magnifica¬ 
tion,  is  capable  of  perceiving  more  detail  than  is  provided  by 
200  lines/inch.  There  may  be  a  significant  market  for  a  fac- 
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simile  system  which  has  sufficiently  high  resolution  that  the 
output  page  could  pass  for  an  original  to  the  casual  observer. 

Delta  Information  Systems  is  performing  a  study  of  resolu¬ 
tion  for  Group  4  equipment  for  the  National  Communications  Sys¬ 
tem.  The  higher  resolutions  which  are  being  examined  include 
240,  300,  400,  and  480  lines/inch.  One  disadvantage  of  240  lines/ 
inch  is  that  if  may  not  be  a  sufficient  increase  relative  to 
200  lines/inch.  It  is  unlikely  that  480  lines/inch  will  be  chosen 
due  to  the  severe  penalty  in  bits/document,  and  hardware  cost  to 
implement  such  a  high  resolution.  Further  it  is  unlikely  that 
the  image  quality  at  480  lines/inch  would  be  significantly  su¬ 
perior  to  that  at  400  lines/inch. 

It  is  possible  that  a  higher  resolution  other  than  300  lpi 
or  400  lpi may  be  chosen- -e.g.  360  lpi.  Nevertheless  it  is  useful 
to  focus  our  attention  on  the  comparison  between  30i*  md  400 
lines/inch.  These  two  resolutions  are  compared  below  from  sev¬ 
eral  different  points  of  view. 

-Image  Quality  --  The  perceived  legibility/quality  of  a 
facsimile  image  at  300  lines/inch  is  quite  high.  As  an  example 
of  this  quality  Addressograph  Multigraph  International  has  pro¬ 
vided  output  copies  of  the  8  CCITT  documents  which  have  been 
transmitted  through  their  300  lines/inch  facsimile  system. 

Copies  are  included  in  Figures  4-1  through  4-8.  Experiments 
have  been  performed  with  300  lines/inch  output  documents  which 
suggest  the  casual  observer  considers  th -•*  o  be  "originals." 

-Bits/Page  -  There  are  78%  more  pels  in  a  400  lines/inch 
page  relative  to  a  300  lines/inch  image.  However,  the  compres- 
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THE  SLEREXE  COMPANY  LIMITED 

SAPORS  LANE  •  BOOLE  •  DORSET  -  BH25  8  ER 
TELEPHONE  MOLE  (945  13  )  51617  •  TELEX  123456 


Our  Ref.  350/P JC/EAC  18th  January,  1972. 


Dr.  P.N.  Cundall, 
Mining  Surveys  Ltd., 
Holroyd  Road, 
Reading, 

Berks . 


Dear  Pete, 

Permit  roe  to  introduce  you  to  the  facility  of  facsimile 
transmission. 

In  facsimile  a  photocell  is  caused  to  perform  a  raster  scan  over 
the  subject  copy.  The  variations  of  print  density  on  the  document 
cause  the  photocell  to  generate  an  analogous  electrical  video  signal. 
This  signal  is  used  to  modulate  a  carrier,  which  is  transmitted  to  a 
remote  destination  over  a  radio  or  cable  communications  link. 

At  the  remote  terminal,  demodulation  reconstructs  the  video 
signal,  which  is  used  to  modulate  the  density  of  print  produced  by  a 
printing  device.  This  device  is  scanning  in  a  raster  scan  synchronised 
with  that  at  the  transmitting  terminal.  As  a  result,  a  facsimile 
copy  of  the  subject  document  is  produced. 

Probably  you  have  uses  for  this  facility  in  your  organisation. 

Yours  sincerely, 

Sd. 

P.J.  CROSS 

Group  Leader  -  Facsimile  Research 
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L'ordred*  lmww>  at  de  realisation  4u  applications  fait  l'objat  da  ddclston*  au  plus  ljut 
niveau  de  la  Direction  General*  dta  Telecommunications.  Q  n'eet  cartas  pea  question  da 
cooatruira  c*  systdma  Integra  "an  bloc"  mala  bias  an  contrairc  da  proebdar  par  diapaa,  par 
pattaro  aaccaaaUa.  Certain#  s  appUcatioaa.  dont  !a  rantabilitd  aa  pourrm  atra  aaaorda.ia 
aaront  paa  aetraprlses.  ActuaUamaot.  aor  tranta  appUeationa  qui  oat  pa  atra  global#  ment 
ddCkdaa,  six  an  aont  aa  atada  da  l'expioi  tattoo,  aU  autraa  aa  scat  vu  deonar  la  prior  it  4  pour 
Imf  riiflullfin 

fliaifi-  appllcaiion  aat  confide  4  an  "chef  da  projat",  raaponabbla  succe salve  meat  da  aa 
conception,  da  aon  analyse- programmatic*  at  da  aa  miaa  aa  oeevra  dans  tma  region -pilot*. 
La  fdndrallaaKon  ultdrtenr*  da  l'epplicatton  realise*  dana  catte  region-pilot*  depend  daa 
rdeuitats  nlitama  at  tail  rob  jet  d'un#  decision  da  la  Direction  Cdndrala.  Ndanmoina.  la 
chsf  da  projat  doit  dta  la  ddpart  conaiddrar  qne  aon  activttd  a  une  vocation  national*  done 
refoeer  tont  particularism*  regional,  n  eat  aide  d'une  equip*  d'analyoteo-programmeurs 
ot  ontoare  d'tm  "group*  da  concaption"  charge  da  rddigar  la  document  da  "definition  daa 
objectlfs  globaux"  pula  la  "cafcior  daa  charges”  do  l'applicatioa.  qui  aont  odraoodo  pour  avia 
k  ton a  lea  services  utiliaataura  potentials  at  ana  chafe  da  projat  daa  autraa  applications. 
La  groaps  da  conception  comprasd  •  4  10  personae*  raprdaantant  las  services  las  pins 
divers  concern**  par  1*  projat, et  comport*  obligatoire m*nt  ua  boa  analyst*  attach#  4  I'ap- 
pli  cation. 


n  •  L’implantatiok  geographique  D'un  resea i:  informatique  performant 

L’ organisation  dc  l'sntraprla*  franqaiaa  das  telecommunications  repoos  sur  l'exlstoncc  do 
20  regions.  Dos  calculators  oat  ete  implants*  dans  le  passe  au  moins  dans  toutca  lea  phis 
Important**.  Outran**  alnai  d*s  machine*  Bull  Gamfita  30  4  Lyon  et  Marseille .  daa  GE  425 
4  LIU*.  Bordeaux.  Toulouse  et  Montpellier,  un  GE  437  4  Massy,  enfin  qualques  machines 
Ball  300  T1  4  programmes  ctbldc  d talent  rdeemment  ou  sent  encore  en  service  dana  l*s 
regions  da  Nancy,  Nantas.  Limoges,  Foitiars  at  Rouen  ;  ce  pare  cat  essentia  llament  utilise 
poor  la  comptabilite  teidphoniqo*. 

Al'avaair,  alia  phi  part  das  flchiers  ndcasaairas  aux  applications  ddcrite#  plus  haul  peuvent 
dtra  gdrd*  an  tamps  diffdre.  ua  certain  nombra  d'entrs  eux  devront  ndeesaairamant  dtre  ac- 
caaaiblaa.  voire  mi*  4  Jour  en  temps  reel  :  parml  cos  dernier*  1*  fichier  commercial  das 
abonnds.  la  fichier  das  rawneigne manta,  la  fichier  dee  circuits,  1*  fichier  technique  das 
aboands  caatteadroat  das  quantitda  considerable*  d'informatlon*. 

La  volume  total  da  caractdFee  4  gdrer  en  phase  finale  sur  un  ordinateur  ay  ant  en  charge 
qaalqnaa  300  000  aboands  a  dtd  estimd  4  un  milliard  de  caractdres  au  moina.  Au  moins  le 
tier*  da*  donndes  aaront  concerndea  par  de*  traitements  en  tempe  rdel. 

Aucun  das  calculataurs  dnumdrds  plus  haut  ne  permettait  d'envisager  da  tel*  traitements. 
L'intdgratlon progressive detoatea le#  applications  suppose  la  erdation  d'un  support  commun 
pour  touts*  le*  informations,  une  veritable  "Banque  de  donndea",  rdpartie  sur  dea  moyens 
detraitement  nationaux  et  rdgionaux,  et  qui  devra  rester  alimente*.  mis*  4  Jour  en  perms* 
nance,  4  pnrtir  de  la  baas  d*  l'entreprisa ,  c'est-4-dire  les  chantiers,  lea  magasins,  lea 
gulchets  dea  aervlcea  d'abonnement.  les  services  de  personnel  etc. 

L' etude  daa  different#  flchiers  4  constituer  a  done  pdrmis  de  ddfinir  les  principal**  carac- 
tdrlstiquea  du  rdseau  d'ordinateurs  nouveaux  4  mettre  en  place  pour  aborder  la  realisation 
du system*  informatif .  L' obligation  d*  fair*  appel  4  des  ordinateurs  de  troisidme  generation, 
trds puissant* et dotd* d*  vohimineu ses  memoir*#  de  masse,  a  conduit  4  en  rdduire  substan¬ 
tial^  men  t  1*  nombre. 

L  'Implantation  d*  sept  centres  da  calcul'  inter  rdgionaux  constituent  un  compromts  entre  : 
d'un* parti*  ddalr  de  rdduire  1*  codt  deonomique  de  l'ensemble,  de  faciliter  la  coordination 
des  dquipas  d'informaticiens;  et  d'autre  part  le  refus  d*  crOer  dea  centres  trap  important# 
difficile*  4  gdrer  et  d  diriger.et  posant  des  probldmes  ddlicats  dc  sdcuritc.  Le  regroupe- 
ment  des  traitements  rslatifs  4  plusieurs  regions  sur  chacun  da  ces  sept  centres  permettra 
de  laar  donner  une  tailla  ralativemant  homogdn*.  Chaque  centre  "gvrera"  environ  un  mil¬ 
lion  d’abonne*  4  la  fin  du  Vldme  Plan, 

La  miss  en  place  da  ces  centra*  a  ddbutd  au  ddbut  do  l'anndo  197 1  :  un  ordinateur  IRIS  >0  da 
la  Compagnie  Internationale  pour  l'Informatique  a  dtd  install*  4  Toulouse  en  fdvrier  ;  la 
rndma  machiaa  viaat  d'etre  mis*  an  service  au  centre  de  calcul  interregional  de  Bordeaux. 

Figure  4-4 


Cek  est  d'sutant  plus  valable  que  T&f  sst  plus 
grand.  A  cst  dgard  la  figure  2  reprdsentc  Is  vraie  courbc 
donna*  ldO)l en  fonction  de/pour  les  vakurs  niund- 
nquet  mdiqudes  page  prdcdtknte. 


Dana  ce  cas,  k  fibre  adapt*  pourra  etre  constitud, 
conformdment  a  la  figure  3.  par  la  cascade  : 

—  d'un  flhre  pasie-bande  de  traiwfen  unit*  pour 
/o  <  /  <  /e+A/  «  de  transfert  quasi  nul  pour 
/</„«/:>  /0+A/,  fibre  nemodifiant  pas  la  phase 
des  composanis  le  traversam  ; 
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—  fibre  suivi  d'une  ligne  i  retard  (LAR)  disper¬ 
sive  ayant  un  temps  de  propagation  de  groupc  T, 
ddcroissam  lindairement  avee  la  frequence  /  suivant 
{’expression  : 


7’a«r.+(/,-/)-f- 

A/ 


(avec  T,  >  T) 


(voir  fig.  4). 


Figur«  4-5 
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tells  ligne  I  retard  est  donnee  par  : 

9  -  -2*  d/ 

Et  cette  phase  est  been  I'opposd  de 

it  un  ddphasage  constant  prds  (sans  importance) 

et  i  un  retard  Tt  prds  (indvitabk). 

Un  signal  utile  S(f)  traversam  un  tel  (litre  adapter 
donne  it  la  sortie  (4  un  retard  Tt  prds  et  it  un  ddpha¬ 
sage  prds  de  la  porteuse)  un  signal  dont  la  transformee 
de  Fourier  est  rdelle,  consume  entre  /<,  et  f0  +  A/, 
et  nulle  de  part  et  d’autre  de  /0  et  de  /o  +  AA  e’est- 
i-dtre  un  signal  de  frdquence  porteuse  A+A/72  et 
dom  I’envdoppe  e  la  Tonne  indiqude  it  la  figure  3, 
ou  Ton  a  reprdsentd  simubandment  le  signal  S(i) 
et  le  signal  S,(i)  correspondent  obtenu  4  la  sonie 
du  fibre  adapt*.  On  comprend  le  nom  de  rdeepteur 
4  compression  d’impulsion  donnd  4  ce  genre  de 
fibre  adaptd  :  la  «  targeur  »  (4  3  dB)  du  signal  com- 
primd  dtant  dgale  4  I/Af,  le  rapport  de  compression 

est  de  -I—  m  TAf 
1/A/ 


On  saisit  physiquemem  le  phdnotndnc  de  com¬ 
pression  en  rdalisant  qua  lorsque  le  signal  S(t)  entre 
dans  la  ligne  4  retard  (LAR)  la  frequence  qui  entre 
la  premidre  4  I'insunt  0  est  la  frdquence  basse  /#, 
qui  met  un  temps  T«  pour  traverser.  La  frdquence  / 

entre  4  ('instant  i  -  (/-/,)  —  et  elk  met  un  temps 


r«-(/  -/a)  —  pour  traverser,  ce  qui  la  fait  ressortir 
4  I’bistant  T.  d— lament.  Ainsi  done,  k  sienal  S(t\ 
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Figure  4-7 
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sion  ratio  is  greater  at  400  lpi  than  at  300  lpi  so  the  net  in¬ 
crease  in  the  bits/page  is  undoubtedly  less  than  50%.  Neverthe¬ 
less  the  penalty  in  bits/page  for  400  lpi  over  300  lpi  would  be 
significant  when  considering  the  communication  cost  and  computer 
storage  cost. 

-Compatibility  with  200  lpi  -  The  400  lpi  standard  is  advan¬ 
tageous  since  it  is  an  integral  multiple  of  200  lpi- -the  antici¬ 
pated  lower  resolution  standard.  One  advantage  stems  from  the 
fact  that  it  would  be  easy  to  interpolate  a  400  lpi  image  at  the 
receiver  from  a  transmitted  200  lpi signal.  Another  advantage  is 
the  manufacturing  compatibility  at  these  two  resolutions. 

-Existing  Equipment  -  In  the  United  States  there  is  much 
more  euipment  in  the  marketplace  operating  at  300  lpi  than  at 
400  lpi. 

-Compatibility  with  Text  -  This  text  compatibility  issue  is 
not  a  major  point  but  it  is  worth  mentioning.  The  most  standard 
spacing  for  text  is  10  characters/inch  horizontal  and  6  charac¬ 
ters/inch  vertical.  Therefore  it  would  be  desirable  for  the 
pel  resolution  to  be  an  integral  multiple  of  60  so  that  a  charac¬ 
ter  space  (1/10  inch  horizontal  x  1/6  inch  vertical)  could  contain 
an  integral  number  of  pels.  This  issue  favors  300 lpi.  This  issue 
is  obviously  raised  in  anticipation  of  those  situations  where  text 
will  be  integrated  with  facsimile  graphics. 
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5.0  COMPRESSION  TECHNIQUE 


There  are  two  broad  classes  of  black-white  graphic  coding 
techniques : 

-Information  preserving  techniques  -  those  which  repro¬ 
duce  an  exact  replica  of  the  original  scanned  and 
thresholded  binary  image. 

-Approximation  techniques  -  those  which  knowingly  repro¬ 
duce  an  approximation  of  the  original  scanned, 
thresholded  binary  image. 

These  two  categories  are  discussed  in  Sections  5.1  and 
5.2  respectively.  A  brief  look  at  other  coding  techniques  is 
provided  in  Section  5.3. 

5.1  Information  Preserving  Techniques 

The  standard  compression  technique  for  Group  3  facsimile 
equipment  is  the  Modified  Huffman  Code  (MHC) ,  a  run  length  coding 
algorithm  which  reduces  redundancy  in  only  one  dimension.  The 
Group  3  standard  also  provides  for  an  optional  compression  tech¬ 
nique  which  reduces  redundancy  in  two  dimensions--the  Modified 
Read  Code  (MRC) .  Both  of  these  coding  techniques  are  exact  com¬ 
pression  algorithms  which  preserve  all  the  image  information. 

Table  5-1  is  a  summary  of  compression  ratios  for  four  of 

2 

the  more  prominent  coding  techniques- -MHC,  MRC,  Ordering  tech¬ 
nique,3  and  Symbol  Matching.4  The  compression  data  is  provided 
for  the  8  CCITT  test  documents  shown  in  Figure  5-1.  The  Ordering 
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TABLE  5-1 

COMPRESSION  FOR  DIGITAL  FACSIMILE  COMPRESSION  TECHNIQUES** 


High  Performance  Coder  **  Vertical  resolution-  7.7  li/nin 


FIGURE  5-1  CCITT  Standard  Documents  for  Data  Compression  Analysis 


technique  is  a  two-dimensional  compression  concept  which  yields 
virtually  the  same  compression  as  the  Modified  Read  Code.  Since 
the  MRC  is  the  Group  3  standard  there  is  little  motive  to  choose 
the  Ordering  technique  for  Group  4. 

The  standard  Minimum  Scan  Line  Time  (MSLT)  for  Group  3 
is  20  ms.  The  standard  K-factor  for  the  MRC  at  200  lines/inch  is 
4  to  1.  This  means  that  every  fourth  line  is  transmitted  with 
the  MHC  to  minimize  the  vertical  propagation  of  transmission 
errors.  Under  these  operating  conditions  the  average  compression 
ratio  for  the  MHC  and  MRC  is  7.07  and  9.44  respectively;  i.e., 
the  performance  of  the  MRC  is  only  331  superior  to  the  MHC.  How¬ 
ever,  in  Group  4,  the  error  rate  will  be  very  low  so  the  K-factor 
can  be  made  infinite.  In  addition,  the  limitations  of  the  docu¬ 
ment  transport  can  be  ignored  in  Group  4  so  the  MSLT  can  be  con¬ 
sidered  to  be  zero.  Under  these  conditions  the  MRC  outperforms 
the  MHC  by  81^.  For  the  MRC,  the  compression  ratio  for  document 
number  four,  the  full  page  of  text,  is  7.02.  The  average  ratio 
for  all  8  documents  is  approximately  14  to  1. 

The  Group  3  standard  requires  the  transmission  of  a  12-bit 
End-of-Line  code  between  scan  lines.  To  further  increase  the 
compression  ratio  it  may  be  possible  to  delete  these  line  syn¬ 
chronization  codes.  If  this  were  done  the  compression  ratio 
would  increase  by  approximately  10%. 

The  data  in  Table  5-1  was  measured  for  the  Group  3  high 
resolution  of  200  lines/inch.  Compression  ratios  have  been  re¬ 
cently  measured  for  the  MRC,  at  300  lines/inch,  by  AM  Interna¬ 
tional.  The  results  are  listed  in  Table  5-2.  Data  is  included 
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TABLE  5-2 

COMPRESSION  RATIOS  FOR  THE  MOD 
READ  CODE  AT  300  lines/in< 


CCITT 

Document 

No. 

Horizontal 

Scan 

1 

36.9 

2 

52.2 

3 

25.5 

4 

10.9 

5 

22.9 

6 

38.2 

7 

10.8 

8 

33.4 

AVG. 

21.7 

Infinity;  MSLT  »  0 


for  the  conventional  horizontal  scanning  direction  as  well  as  for 
the  vertical  mode,  where  the  scan  lines  are  parallel  to  the 
11  inch  dimension  of  the  paper.  Note  that  the  compression  ratio 
in  the  vertical  mode  is  slightly  superior  to  that  in  the  hori¬ 
zontal  mode.  Also  note  the  large  increase  in  average  compression 
ratio  at  300  lpi  (21.7)  relative  to  200  lpi  (13.92).  This  com¬ 
pression  increase  of  561  reduces  the  225%  increase  in  the  number 
of  pels  for  a  net  increase  in  the  average  number  of  transmitted 
bits  to  be  44%. 

In  summary,  an  extension  of  the  Modified  Read  Code 
(K  *00  ,  MSLT  *  0,  perhaps  with  the  EOL  codes  eliminated)  is  a 
strong  candidate  to  be  selected  as  a  standard  compression  tech¬ 
nique  for  Group  4. 
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5.2  Approximation  Techniques 

Smoothing  algorithms,  as  described  in  Section  3.0,  in¬ 
crease  compression,  and  therefore  could  be  considered  a  compres¬ 
sion  technique.  However,  in  this  section  the  discussion  will  be 
limited  to  two  different  types  of  coding  techniques  which  make 
approximations- -  interpolation  techniques  and  feature/symbol 
recognition.  These  coding  concepts  are  discussed  in  Sections 
5.2.1  and  5.2.2  respectively. 

5.2.1  Interpolation  Techniques 

Interpolation  techniques  may  be  employed  at  the  receiver 
if  the  resolution  of  the  printer  is  greater  than  the  resolution 
of  the  scanner.  A  good  example  of  interpolation  is  the  case 
where  the  scanner  transmits  alternate  scan  lines  as  shown  in 
Figure  5-2.  Of  course  the  advantage  of  this  procedure  is  that 
a  compression  ratio  of  2  to  1  is  achieved. 

At  the  receiver  those  scan  lines  which  were  not  trans¬ 
mitted  are  "interpolated"  from  the  adjacent  transmitted  data. 
Figure  5-2  describes  a  possible  algorithm  for  interpolating 
alternate  lines. 

5.2.2  Feature/Symbol  Recognition 

A  large  fraction  of  the  documents  transmitted  through 
facsimile  systems  contain  text  as  opposed  to  graphics.  One  fac¬ 
simile  compression  technique  involves  the  recognition  of  the  text 
characters  and  the  transmission  of  a  short  ASCII-like  code  defin¬ 
ing  the  particular  character  recognized.  The  compression  for  a 
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FIGURE  5-2 
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The  pel  to  be  interpolated  is  designated  as  "x".  The  first  step 
in  the  interpolation  process  is  to  consider  the  pair  of  trans¬ 
mitted  pels  (P(j)  which  are  adjacent  to  "x"  in  the  line  above  and 
below.  If  the  Pq  pels  are  both  black  interpolate  "x"  to  be 

black.  If  the  Po  pels  are  both  white  interpolate  "x"  to  be 

white.  If  the  two  Po  pels  are  of  different  color,  adjacent  pairs 

(P±l,  P±2 ,  etc.)  are  examined  to  determine  the  color  of  the  nearest 

pair  where  both  pels  are  black  or  white.  Pel  "x”  is  interpolated 
to  be  the  color  of  the  nearest  pair  which  is  all  black  or  all 
white.  For  example,  if  pairs  P-2»  P-1/  PQ/  and  Pi  all  have 
differing  colored  pels  in  each  pair,  but  the  pels  in  P2  are 
both  white  then  "x"  is  interpolated  to  be  white.  If  opposite 
colors  are  found  equidistant  from  "x"  then  "x"  is  interpolated 
to  be  white.  For  example,  under  the  following  conditions  "x" 
is.  interpolated  to  be  white. 


P_2  -  both  black 

p-n 

Pfl  >  -  pairs  have  different  colored  pels 

pl  J 

P2  -  both  white 


system  of  this  type  is  obviously  very  high.  W.  Pratt  et  al* 
have  analyzed  a  system  of  this  type  (Combined  Symbol  Matching  - 
CSM) ,  and  the  compression  results  are  listed  in  Table  5-1. 

Note  that  the  compression  ratio  for  document  number  4,  the  page 
full  of  text,  has  a  compression  ratio  of  22.4  for  symbol  match¬ 
ing  as  opposed  to  7.02  for  the  Modified  READ. 

If  conventional  ’’OCR"  techniques  were  used  to  recognize 
the  symbols,  a  prohibitive  amount  of  logic  would  be  required  to 
store  the  characteristics  of  all  the  possible  text  symbols  which 
might  be  encountered.  The  CSM  system  gets  around  this  problem  by 
using  the  symbols  in  the  input  document  itself  as  reference  pat¬ 
terns  for  subsequently  scanned  characters.  When  a  new  symbol  is 
encountered,  the  bit  pattern  is  transmitted  to  the  receiver  and 
stored,  as  well  as  being  stored  in  a  library  in  the  transmitter. 
When  another  symbol  is  encountered  which  is  similar  to  that  stored 
(it  need  not  be  identical),  a  short  ASCII-like  code  is  transmitted 
to  the  receiver.  The  appropriate  bit  pattern  is  retrieved  from 
the  library  and  printed.  Of  course  those  parts  of  the  page  which 
are  not  recognizable  as  symbols  are  transmitted  by  a  conventional 
compression  technique , such  as  the  MRC. 

Other  types  of  recognition  systems  are  possible.  For  ex¬ 
ample,  it  would  be  possible  to  recognize  small  "features”*  which 
are  commonly  found  in  documents*  as  opposed  to  complete  charac¬ 
ters.  Possible  features  are  short  straight  line  segments  at 
various  angles,  arcs,  etc.  In  this  way,  complex  characters  would 
be  synthesized  from  simple  small  features. 

Recognition  systems  of  this  type  are  not  without  their 
problems.  One  difficulty,  of  course,  is  their  complexity.  An- 
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other  is  the  potential  substitution  of  one  character  for  another- 
(e.g.  B/8,  a/e,  s/o,  etc.)*  Nevertheless,  the  general  concept 
of  recognition  is  very  appealing  for  Group  4  operation  since  one 
is  beginning  to  create  "data"  for  the  data  network.  Another  ad¬ 
vantage  of  the  recognition  technique  is  that  it  is  compatible 
with  the  potential  integration  of  facsimile  and  word  processing 
systems . 

5.3  Other  Coding  Techniques 

It  is  probably  premature  to  seriously  consider  setting 
standards  for  the  transmission  of  continuous  tone  and  color 
imagery.  Nevertheless  it  may  be  appropriate  to  give  some  thought 
to  these  possible  future  requirements  to  avoid  their  exclusion 
at  a  later  date.  For  example,  continuous-tone  imagery  could  pos¬ 
sibly  be  coded  by  pseudorandomly  dithering  the  threshold  level 
in  the  transmitter. 
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6.0  DATA  RATES 


CCITT  Recommendation  X.l  defines  four  data  signalling 
rates  for  packet  switched  networks- -2. 4,  4.8,  9.6,  and  48.0  kbps. 
Therefore  it  is  likely  that  these  rates  will  be  chosen  as  stan¬ 
dard  data  rates  for  Group  4  operation.  The  lower  da  dtes-- 
2.4,  4.8,  9.6  kbps --are  particularly  appropriate  since  they  also 
conform  to  the  Group  3  standard. 

There  are  two  other  data  rates  in  the  region  of  48  kbps, 
which  will  be  considered  for  standardization- -56  kbps  and  64  kbps 
The  56  kbps  is  provided  by  AT  8  T  as  a  switched  data  service 
(Dataphone)  in  metropolitan  areas.  Hence,  it  may  be  wise  to 
select  this  rate  as  a  standard.  The  INTELPOST  electronic  mail 
system  is  an  example  of  a  facsimile  system  transmitting  at 
56  kbps.  It  is  useful  to  examine  the  typical  document  transport 
rates  at  56  kbps.  If  one  considers  a  resolution  of  200  lpi,  and 
an  average  compression  of  14,  the  number  of  bits/page  is  approxi¬ 
mately  300,000  bits.  Such  a  document  would  be  transmitted  over 
a  56  kbps  channel  in  approximately  5  seconds,  a  very  reasonable 
time  to  mechanically  transport  a  page. 

There  is  some  consideration  of  facsimile  equipment  operat¬ 
ing  at  data  rates  even  higher  than  56  kbps.  For  example.  Satel¬ 
lite  Business  Systems  offers  data  rates  at  112,  224,  and  448  kbps 
And  of  course  the  T-l  rate  of  1.544  mbps  is  commonly  available. 
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7.0  COMMUNICATIONS  PROTOCOL 


As  explained  in  Section  2.0  the  CCITT  has  developed  an 
interface  standard- -X. 25- -defining  the  interconnections  between 
a  data  terminal  equipment  and  a  packet  switched  network. 

Figure  7-1  is  a  block  diagram  illustrating  the  three  architec¬ 
tural  levels  of  the  X.2S  standard.  Appendix  A  contains  a  copy 
of  the  X.25  standard  for  reference  purposes.  It  is  clear  that 
the  X.25  protocol  will  be  adopted  as  part  of  the  Group  4  fac¬ 
simile  standard.  As  shown  in  Figure  7-1  and  Table  7-1,  the 
X.25  standard  uniquely  defines  the  third  level- -the  network  or 
packet  level.  At  the  second  level  X.25  embraces  the  HDLC/LAPB 
standard  which  has  been  promulgated  by  the  ISO  group.  For  the 
first  level--the  physical  level--it  refers  to  X.21  as  the  stan¬ 
dard.  It  is  likely  that  the  Group  4  standard  will  also  include 
two  other  commonly  used  physical  standards  as  options- -RS232C 
and  RS449. 

Figure  7-1  illustrates  a  user  terminal  connected  to  the 
data  network  via  an  external  modem.  It  is  possible  that  the 
Group  4  facsimile  unit,  like  the  Group  3  unit,  may  be  used  on 
the  public  telephone  network.  In  these  instances  a  new  archi¬ 
tectural  layer- -level  0--has  been  defined  to  specify  the  modem 
to  be  a  V.27ter  or  V.29  modem.  This  corresponds  to  the  Group  3 
standard.  Another  layer- -level  00- -has  also  been  defined  to 
specify  the  means  to  interconnect  the  terminal  to  the  telephone 
network. 

The  National  Communications  System  has  developed  a  series 
of  Federal  Standards  which,  in  most  instances,  are  closely  re¬ 
lated  to  certain  CCITT  and  EIA  standards.  A  list  of  the  Federal 
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25  INTERFACE  STANDARD 


TABLE  7-1 

COWUNICAT1CNS  HHERFACE  FOR  GROUP  4  FACSIMILE 


LAVER 

LAVER 

1 - ! 

j  APPLICABLE  j 

1  i  '  , 

i  ' 

FUNCTION 

NO. 

NAME 

j  STANDARD 

j  ; 

» 

5%  DOCUMENT 

! 

i 

TELETEX 

S.d 

S .  62 

i 

• 

Document  start/end;  ocntnittment  unit 

i 

! 

. 

1  ! 

J  5  SESSION 

TELETEX 

S.d 

S.62 

Synchronization  of  the  application;  who  talk?  first, 
time,  date,  subscriber  number;  broadcast  control 

|  ; 

1  4  j  TRANSPORT 

j 

:  1 

TELETEX 

S.h 

S .  70 

Assures  end-to-end  data  integrity  and  provides  for  the 
required  quality  of  service  for  exchanged  information; 
intelligent  front  end  deciding  on  type  of  network 

_ _ _ _ _ _ _ 

MODULATION 


INTERCONNETT 


HDI C  LAPB 

| 

l 

|  The  link  access  procedure  for  reliable  data  interchange 
|  across  the  link  between  the  DTE  and  the  data  netarork; 
j  error  handling;  flow  control;  e.g.  "rcvr  ready", 

"rcvr  not  ready" 

- 

X.21 

RS449 

RS232 

The  physical,  electrical,  functional*  and  procedural 
characteristics  to  establish*  maintain,  and  disconnect 
the  physical  link  between  the  DTE  and  the  network 

v.27  ter 
v.29 

Used  when  the  DTE  is  connected  to  the  network  via  a 
contnunication  chennel 

-3 


standards,  which  correspond  to  the  standards  mentioned  above,  are 
listed  below. 


Federal  Standard 
1041  (Interim) 
1003 

1040  (Proposed) 

1031 

1006 

1007 


Equivalent  Standard 
X.  25 

HDLC/LAPB 
X.  21 
RS449 
•  V.27ter 
V.  29 


The  International  Standards  Organization  (ISO)  has  developed 
an  architectural  framework  for  defining  standards  for  linking 
heterogeneous  computer  networks.  The  proposed  architecture- - 
the  Open  Systems  Interconnection  (OSI)  reference  model - -provides 
the  basis  for  interconnecting  "open"  systems  for  distributed 
applications  processing.  The  term  "open"  denotes  the  ability 
of  an  end- system  (user  terminal  or  host  computer)  of  one  manu¬ 
facturer/design  to  connect  with  any  other  end- system  conforming 
to  the  reference  model. 

The  OSI  reference  model  contains  the  seven  layers  which 
are  listed  in  Table  7-1.  Layers  00,  0,  and  51  do  not  correspond 
to  the  OSI  model.  If  the  Group  4  facsimile  equipment  is  to  take 
full  advantage  of  the  flexibility  and  universality  of  the  future 
data  networks  it  is  clearly  desirable  to  conform  to  the  OSI 
reference  model  as  much  as  possible. 

The  CCITT  is  in  the  process  of  developing  a  series  of  stan¬ 
dards  to  permit  the  exchange  of  correspondence  between  communicat¬ 
ing  office  typewriters.  This  new  service,  where  the  basic  ele¬ 
ment  of  correspondence  is  the  page,  is  called  TELETEX.  The 
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TELETEX  standards  are  being  developed  to  be  as  consistent  as 
possible  with  levels  4,  S  and  6  of  the  OSI  model.  It  is  recog¬ 
nized  that  there  is  a  great  deal  of  similarity  between  textual 
systems  like  TELETEX  and  facsimile  systems.  For  this  reason 
there  is  a  very  active  program  to  insure  the  TELETEX  standards 
are  written  such  that  facsimile  systems  are  included.  One  ad¬ 
vantage  of  this  dual-purpose  structure  is  that  the  integration 
of  facsimile  graphics  and  work  processing  systems  will  be  facili¬ 
tated  in  the  future. 

The  TELETEX  standards  have  been  recently  consolidated  into 
a  set  of  five  temporary  documents  listed  below: 


f  .X 

Teletex  Service 

s.c 

Terminal  Equipment 

s.d 

Control  Procedures 

s .  f 

Character  Repertoire 

and  Coded 

Character  Sets 

s.h 

Network  Independent; 

Basic 

Transport  Service 

The  correspondence  between  these  various  documents  and  the 
OSI  reference  model  is  shown  in  Table  7-1.  The  two  most  impor¬ 
tant  documents  from  a  facsimile  standards  perspective  are  s.h 
and  s.d.  These  documents  are  included  in  Appendices  B  and  C 
respectively  for  reference  purposes. 

In  summary,  the  trends  for  standardizing  the  communications 
protocol  for  Group  4  are  becoming  clearly  established.  X.2S  will 
be  the  standard  for  levels  1,  2,  and  3  of  the  OSI  reference  model. 
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A  version  of  the  TELETEX  standard  will  probably  be  adopted  for 
levels  4,  5,  and  6. 


8.0  SUMMARY  AND  CONCLUSIONS 

It  is  conducted  that  there  is  no  need  to  standardize  the 
pre-processing,  post  processing,  and  storage  functions  of 
the  Group  4  facsimile  equipment.  On  the  other  hand  it  is 
concluded  that  the  following  parameters  of  the  Group  4  apparatus 
must  be  standardized  to  achieve  interoperability. 

o  Resolution 
o  Compression  technique 
o  Data  rates 

o  Communications  protocol 

Each  of  these  parameters  has  been  separately  discussed  in 
Sections  4.0,  5.0,  6.0,  and  7.0  respectively.  The  results  of 
these  investigations  are  summarized  in  Table  8-1.  For  each  of 
the  four  parameters  those  potential  standards  which  are  most 
likely  to  be  selected  are  highlighted  along  with  those  which  are 
secondary  but  receiving  serious  consideration. 


TABLE  8-1 

SUMMARY  OF  POTENTIAL  GROUP  4  STANDARDS 


PARAMETER 

POTENTIAL  STANDARDS 

STRONG  CANDIDATE 

OTHER 

RESOLUTION 

GROUP  3 

HORIZONTAL-  200  lpi 

VERTICAL  -  100,  200 

300  lines/inch 

400 

Other 

COMPRESSION 

TECHNIQUE 

EXTENSION  OF  THE 

MODIFIED  READ  CODE 

o  K  *  CD 

o  MSLT  -  0  ms. 

o  Eliminate  EOL  Codes 

o  Skip  alternate  lines/ 
Interpolate  at  Rcvr. 

o  Symbol  Recognition 

DATA  RATES 

KBPS 

2.4,  4.8,  9.6,  48.0 

56.0,  64.0 

112,  224,  448 

1,544.0 

COMMUNICATIONS 

PROTOCOL 

OS  I 

LAYER  # 

1 

X . 21 ,  RS  449,  RS  232 

2 

HDLC/LAPB 

3 

X .  25 

4 

TELETEX  S . h/S . 70 

5,  5H 

TELETEX  S. d/S. 6 2 

6 

TELETEX  S . f/S . 61 

9.0  RECOMMENDATIONS  FOR  FURTHER  STUDY 

Based  upon  the  results  of  this  study  it  is  concluded  that 
the  Group  4  standardization  process  would  be  facilitated  by  ad- 
ditional  studies  in  the  three  particular  areas  described  below: 

-RESOLUTION  --  It  is  likely  that  the  Group  4  standard  will 
include  a  resolution  higher  than  the  200  lpi  Group  3  resolution. 
Unfortunately  there  is  little  hard  data  regarding  the  legibility/ 
quality  of  digital  facsimile  systems  at  varying  resolutions. 

It  is  recommended  that  such  a  study  be  undertaken  covering  the 
resolutions  range  from  200  to  400  lines/inch  or  higher.  Delta 
Information  Systems  is  now  performing  a  contract  (DCA100-80-C- 
0042)  for  the  National  Communications  System  to  generate  this 
data.  The  final  report  is  scheduled  to  be  issued  March  31,  1981. 

-COMPRESSION  BY  SYMBOL  RECOGNITION  --  It  is  likely  that 
the  basic  compression  algorithm  for  Group  4  will  be  an  extension 
of  the  Modified  READ  code.  However,  as  pointed  out  in  Section 
5.0,  the  feature/symbol  recognition  technique  is  very  attractive 
for  operation  over  data  networks  and  for  future  integration  with 
word  processing  systems.  Unfortunately  there  has  been  relatively 
little  general  analysis  of  this  compression  technique.  It  is 
recommended  that  a  very  preliminary  study  be  undertaken  to  in¬ 
vestigate  one  of  the  fundamental  issues  in  symbol  recognition 
system- -i.e. ,  how  to  segment  the  image  into  graphic  and  symbol 
parts  and  how  to  form  the  structure  of  the  transmitted  signal. 
Such  a  study  would  not  answer  all  questions  related  to  recogni¬ 
tion  coding  techniques,  but  it  is  an  important  first  step. 
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-THROUGHPUT  ANALYSIS  --  Packet  switched  networks  have  been 
designed  primarily  to  accommodate  short  bursty  messages  between 
user  data  terminals  and  remote  host  computers.  The  network  has 
been  designed  to  be  very  responsive  to  such  short  messages  in 
spite  of  the  fact  that  the  storage  in  the  network  node  is  some¬ 
what  restricted.  Since  the  length  of  a  facsimile  message  is 
extremely  large  relative  to  the  typical  data  message,  there  is 
some  concern  about  the  potential  throughput  of  Group  4  messages 
through  today’s  data  networks.  Another  source  of  concern  about 
throughput  stems  from  the  potential  use  of  the  multi-level  communi 
cations  protocol.  Since  each  protocol  layer  adds  its  own  header 
to  a  message  there  is  a  concern  about  the  potential  buildup  of 
the  communication  overhead.  It  is  recommended  that  these  con¬ 
cerns  be  addressed  in  an  analysis  of  the  potential  throughput  of 
Group  4  facsimile. 
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APPENDIX  A 


DRAFT  REVISED  RECOMMENDATION  X.25 

INTERFACE  BETWEEN  DATA  TERMINAL  EQUIPMENT (DTE)  AND  DATA 
CIRCUIT-TERMINATING  EQUIPMENT  (DCE)  FOR  TERMINALS  OPERATING 
IN  THE  PACKET  MODE  ON  PUBLIC  DATA  NETWORKS 


B 1 

Draft  Revised  Recommendation  X..‘5 

INTERFACE  BETWEEN  DATA  TERMINAL  EQUIPMENT  (DTE)  AND  DATA 
CIRCUIT-TERMINATING  EQUIPMENT  (DCE)  FOR  TERMINALS  OPERATING 
IN  THE  PACKET  MODE  OH  PUBLIC  DATA  NETWORKS 


The  establishment  In  various  countries  of  public  data  networks  providing 
packet-switching  data  transmission  services  creates  a  need  to  produce  standards 
to  facilitate  international  Interworking. 


The  CCITT, 


considering 


a)  that  Recommendation  X.l  Includes  specific  user  classes  of  service 
for  data  terminal  equipments  operating  In  the  packet  mode.  Recommendation  X.2 
defines  user  facilities.  Recommendations  X.21  and  X.21  bis  define  DTE/DCE 
physical  level  interface  characteristics,  Recomnendation  X.92  defines  the 
logical  control  links  for  packet- switching  data  transmission  services  and 
Recommendation  X.96  defines  call  progress  signals; 

b)  that  data  terminal  equipments  operating  In  the  packet  mode  will  send 
and  receive  network  contrc'  information  In  the  form  of  packets; 

c)  that  certain  data  terminal  equipments  operating  in  the  packet  mode 
will  use  a  packet  interleaved  synchronous  data  circuit; 

d)  the  desirability  of  being  able  to  use  a  single  data  circuit  to  a 
DSE  for  all  user  facilities; 

e)  that  Recomnendation  X.2  designates  virtual  call  and  permanent  virtual 
circuit  services  as  essential  (t)  services  to  be  provided  by  all  networks  and 
designates  datagram  service  as  an  additional  (A)  service  which  may  be  provided 
by  some  networks; 

f)  the  need  for  defining  an  International  recommendation  for  the  exchange 
between  DTE  and  DCE  of  control  Information  for  the  use  of  packet-switching  data 
transmission  services; 

g)  that  the  necessary  elements  for  an  interface  recomnendation  should  be 
defined  independently  as: 

Physical  Level  -  The  mechanical,  electrical,  functional  and  procedural 
characteristics  to  activate,  maintain  and  deactivate 
the  physical  link  between  the  DTE  and  the  DCE. 

Link  Level  -  The  link  access  procedure  for  data  Interchange  across 
the  link  between  the  DTE  and  the  DCE. 


Packet  Level  -  The  packet  format  and  control  procedures  for  the  exchange 
of  packets  containing  control  information  and  user  data 
between  the  DTE  and  the  DCE. 

(unanimously)  declares  the  view 

that  for  data  terminal  equipments  operating  in  the  packet  mode: 

1.  The  mechanical,  electrical,  functional  and  procedural  characteristics 
to  activate,  maintain,  and  deactivate  the  physical  link  between  the  DTE  and  the 
DCE  should  be  as  specified  in  1  below, DTE /DCE  interface  characteristics. 

2.  The  link  access  procedure  for  data  interchange  across  the  link  between 
the  DTE  and  the  DCE  should  be  as  specified  in  2  be1ow,££nk  access  procedure 
across  the  DTE/DCE  interface . 

3.  The  packet  level  procedures  for  the  exchange  of  control  information 
and  user  data  at  the  DTE/DCE  interface  should  be  as  specified  in  3  below. 
Description  of  the  packet  level  DTE/DCE  interface. 

4.  The  procedures  for  virtual  call  and  permanent  virtual  circuit 
services  Should  be  as  specified  In  4  below.  Procedures  for  virtual  circuit 
services. 


5.  The  procedures  for  datagram  service  should  be  as  specified  in  5.  below 
Procedures  for  datagram  service. 

6.  The  format  for  packets  exchanged  between  the  DTE  and  the  DCE  should 
be  as  specified  In  6  below, Packet  formats. 

7.  Procedures  and  formats  for  optional  user  facilities  should  be  as 
specified  in  7  bel oh  Procedures  and  formats  for  optional  user  facilities. 


-A  3  - 

CONTENTS 

1.  DTE/DCE  INTERFACE  CHARACTERISTICS  (PHYSICAL  LEVEL) .  5 

1.1  The  Interface  Characteristics  for  a  DTE  Connected 

to  a  Packet  Switched  Data  Transmission  Service  by  a 
Dedicated  Circuit.. . . . . .  5 

1.2  The  Interface  Character istics  and  Procedures  for  a 

DTE  Connected  to  a  Packet  Switched  Data  Transmis¬ 
sion  Service  through  a  Circuit  Switched  Data 
Transmission  Service . . . .  6 

2.  LINK  ACCESS  PROCEDURE  ACROSS  THE  DTE/DCE  INTERFACE .  7 

2.1  Scope  and  Field  of  Application.... . 7 

2.2  Frame  Structure . 7 

2.3  Elements  of  Procedure..... .  11 

2.4  Description  of  the  Procedure .  20 

3.  DESCRIPTION  OF  THE  PACKET  LEVEL  DTE/DCE  INTERFACE .  33 

3.1  Logical  Channels .  34 

3.2  Basic  Structure  of  Packets . 34 

3.3  Procedure  for  Restart .  36 

3.4  Error  Handling .  37 

3.5  Effects  of  the  Physical  Level  and  the  Link  Level  on 

the  Packet  Level . . . . .  38 

4.  PROCEDURES  FOR  VIRTUAL  CIRCUIT  SERVICES .  38 

4.1  Procedures  for  Virtual  Call  Service .  38 

4.2  Procedures  for  Permanent  Virtual  Circuit  Ser¬ 
vice  . 41 

4.3  Procedures  for  Data  And  Interrupt  Transfer .  42 

4.4  Procedures  for  Flow  Control . . . 47 

4.5  Effects  of  Clear,  Reset  and  Restart  Procedures  on 

the  Transfer  of  Packets . 54 

4.6  Effects  of  Physical  and  Link  Level  Failures .  55 


5.  PROCEDURES  FOR  DATAGRAM  SERVICE .  55 

5.1  Procedures  for  Datagram  Transfer .  55 

5.2  Procedures  for  Flow  Control .  57 

5.3  Effects  of  Reset  and  Restart  Procedures  on  the 

Transfer  of  Packets .  62 

5.4  Effects  of  Physical  and  Link  Level  Failures .  62 

6.  PACKET  FORMATS .  6  3 

6.1  General .  63 

6.2  Call  Set-Up  and  Clearing  Packets .  67 

6.3  Data  and  Interrupt  Packets .  .  75 

6.4  Datagram  and  Datagram  Service  Signal  Packets .  77 

6.5  Flow  Control  and  Reset  Packets .  85 

6.6  Restart  Packets.... .  90 

6.7  Diagnostic  Packet .  92 

6.8  Packets  Required  for  Optional  User  Facilities .  94 

7.  PROCEDURES  AND  FORMATS  FOR  OPTIONAL  USER  FACILITIES .  101 

7.1  Procedures  for  Optional  User  Facilities  Associated 

with  Virtual  Circuit  and  Datagram  Services .  101 

7.2  Procedures  for  Optional  User  Facilities  Only  Avail¬ 
able  with  Virtual  Circuit  Services .  107 

7.3  Procedures  for  Optional  User  Facilities  Only  Avail¬ 
able  with  Datagram  Service .  H3 

7.4  Formats  for  Optional  User  Facilities .  H4 

Annex  1  -  Range  of  logical  channels  used  for  Virtual  Calls, 

Permanent  Virtual  Circuits  and  Datagrams  .  123 

Annex  2  -  Packet  Level  DTE/DCE  Interface  State  Diagrams  ....  125 

Annex  3  -  Actions  taken  by  the  DCE  on  Receipt  of  Packets  in 
a  Given  State  of  the  Packet  Level  DTE/DCE  Inter¬ 
face  as  perceived  by  the  DCE  .  129 

Annex  4  -  Packet  Level  DCE  time-outs  and  DTE  time-limits  . . .  137 

Annex  5  -  Coding  of  X.25  Network  Generated  Diagnostic  Fields 
in  Clear,  Reset  and  Restart  Indication  and  Diag¬ 
nostic  Packets  .  141 


1 


DTE/DCE  INTERFACE  CHARACTERISTICS  (PHYSICAL  LEVEL) 


The  DTE/DC E  physical  interface  characteristics  defined  as  the 
Physical  Level  element  shall  be  in  accordance  with  Recommendation 
X.21.  For  an  interim  period,  some  Administrations  or  RPOAs  may 
offer  a  DTE/DCE  interface  at  this  level  in  accordance  with  Recom¬ 
mendation  X.21  bis.  The  exact  use  of  the  relevant  sections  is 
detailed  below. 

1. 1  The  Interface  Characteristics  for  a  DTE  Connected  to  a 

Packet  Switched  Data  Transmission  Service  by  a  Dedicated 
C l rcuit 


1.1.1  X.21 


1.1. 1.1  The  DTE/DCE  physical  interface  elements  shall  be  accord¬ 
ing  to  section  2  of  Recommendation  X.21. 

1.1. 1.2  The  operation  of  test  loops  shall  be  according  to  sec¬ 
tion  7  of  Recommendation  X.21. 

1.1. 1.3  The  procedures  for  entering  operational  phases  shall  be 
as  follows: 

a)  When  the  DTE  signals  c  »  ON,  signals  on  circuit  T  shall 
be  according  to  the  higher  level  procedures  described 
in  the  following  sections  of  this  Recommendation. 

b)  When  the  DCE  signals  1  ■  ON,  signals  on  circuit  R  shall 
be  according  to  the  higher  level  procedures  described 
in  the  following  sections  of  this  Recommendation. 

c)  The  DTE/DCE  interface  should  normally  remain  in  the 
operational  condition  with  both  c  ■  ON  and  i  »  ON  to 
enable  proper  operation  of  the  higher  level  procedures 
described  in  the  following  sections  of  this  Recommenda¬ 
tion  . 

d)  If  a  situation  necessitates  the  DTE  to  signal  DTE  ready 
or  DTE  uncontrolled  not  ready,  or  the  DCE  t*.  signal  DCE 
ready  or  DCE  not  ready,  the  interface  should  return  to 
the  operational  condition  with  both  c  *  ON  and  i  ■  ON 
when  the  situation  is  appropriate  to  enable  normal 
operation  of  higher  level  procedures  described  in  the 
following  sections  of  this  Recommendation. 

1.1.2  X.21  his 


1.1. 2.1  The  DTE/DCE  physical  interface  elements  shall  be  accord¬ 
ing  to  section  1  of  Recommendation  X.21  bis. 
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1.1. 2. 2  Failure  detection  and  fault  isolation  shall  be  according 
to  section  3  of  Recommendation  X. 21  bis. 

1.1. 2. 3  When  circuits  105,  JOfi,  107,  108  and  109  are  in  the  ON 
condition,  signals  on  circuits  103  and  104  shall  be  according  to 
the  higher  level  procedures  described  in  the  following  sections 
of  this  Recommendation. 

1 . 2  The  Interface  Characteristics  and  Procedures  for  a  DTE  Con¬ 
nected  to  a  Packet  Switched  Data  Transmission  gervice 
Through  a  Circuit  Switched  Data  Transmission  Service 


Note i  The  full  interworking  regarding  the  user  facilities  and 
architectural  aspects  of  the  following  interface  charac¬ 
teristics  and  procedures  are  a  subject  of  further  study. 

1.2.1  X .  21 

1.2. 1.1  The  DTE/DCE  physical  interface  elements  shall  be  accord¬ 
ing  to  section  2  of  Recommendation  X. 21.  The  procedures  for  cir¬ 
cuit  switched  access  shall  be  according  to  sections  3,  4,  5.1  and 
6  of  Recommendation  X.21. 

1.2. 1.2  The  operation  of  test  loops  shall  be  according  to  sec¬ 
tion  7  of  Recommendation  X.21. 

1.2. 1.3  When  c  *  ON  and  i  •  ON  (X.21  state  12  or  13),  signals  on 
circuits  T  and  R  shall  be  according  to  the  higher  level  pro¬ 
cedures  described  in  the  following  sections  of  this  Recommenda¬ 
tion. 


1.2.2  X.21  bis 

1.2.2. 1  The  DTE/DCE  physical  interface  elements  and  call  estab¬ 
lishment  procedures  shall  be  according  to  section  2  of  Recommen¬ 
dation  X.21  bis. 

1.2. 2. 2  Failure  detection  and  fault  isolation  shall  be  according 
to  section  3  of  Recommendation  X.21  bis. 

1.2. 2.3  When  circuits  105,  106,  107,  108  and  109  are  in  the  ON 
condition,  signals  on  circuits  103  and  104  shall  be  according  to 
tha  higher  level  procedures  described  in  the  following  sections 
of  this  Recommendation. 
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LINK  ACCESS  PROCEDURE  ACROSS  THE  DTE /DCS  INTERFACE 


2. 1  Scope  and  Field  of  Application 

2.1.1  The  link  access  procedures  (LAP  and  LAPB)  are  described  as 
the  Link  Level  elements  and  are  used  for  data  interchange  between 
a  DCE  and  a  DTE  operating  in  user  classes  of  service  8  to  11  as 
Indicated  in  Recommendation  X. 1. 

2.1.2  The  procedures  use  the  principle  and  terminology  of  the 
High  Level  Data  Link  Control  (HDLC)  procedure  specified  by  the 
International  Organization  for  Standardization  (ISO). 

2.1.3  The  transmission  facility  is  duplex. 

2.1.4  DCE  compatibility  of  operation  with  the  ISO  balanced  class 
of  procedure  (Class  BA,  options  2,8)  is  achieved  using  the  provi¬ 
sions  found  under  the  headings  annotated  as  "applicable  to  LAPB" 
in  this  Recommendation. 

DTE  manufacturers  and  Implementors  must  be  aware  that  the  pro¬ 
cedure  hereunder  described  as  LAPB  will  be  the  only  one  available 
in  all  networks. 

Likewise,  a  DTE  may  continue  to  use  the  provisions  found  under 
the  heading  annotated  as  "Applicable  to  LAP"  in  this  Recommenda¬ 
tion  (in  those  networks  supporting  such  a  procedure),  but  for  new 
DTE  implementations,  LAPB  should  be  preferred. 


Note:  Other  possible  «ippl  ications  for  further  study  are,  for 

example: 

-  two-way  alternate,  asynchronous  response  mode 

-  two-way  simultaneous,  normal  response  mode 

-  two-way  alternate,  normal  response  mode 
2. 2  Prame  Structure 


2.2.1  All  transmissions  are  in  frames  conforming  to  one  of  the 
formats  of  Table  2.1/X.25.  The  flag  preceding  the  address  field 
is  defined  as  the  opening  flag. 
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TABLE  2.1/X.2S  -  Frame  formats 


Bit 

order 

of 

trans¬ 
mission  ]2345*7P  12345*78  12345*78  1*  to  1  12345P7P 


FCS«frame  checking  sequence 


Bit 

order 

of 

trans¬ 
mission  12345*78  12345678  12345*78  lfi  to  1  12345*78 


FCS«frame  checking  sequence 


2.2.2  Flag  Sequence 

All  frames  shall  start  and  end  with  the  flag  sequence  consisting 
of  one  0  followed  by  six  contiguous  Is  and  one  0.  A  single  flag 
may  be  used  as  both  the  closing  flag  for  one  frame  and  the  open¬ 
ing  flag  for  the  next  frame. 

2.2.3  Address  Field 

The  address  field  shall  consist  of  one  octet.  The  coding  of  the 
address  field  is  described  in  2.4.2  below. 
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2.2.4  Control  Field 

The  control  field  shall  consist  of  one  octet.  The  content  of 
this  field  is  described  in  2.3.2  below. 

Note:  The  use  of  the  extended  control  field  is  a  subject  for 

further  study. 

2.2.5  Information  Field 


The  information  field  of  a  frame  is  unrestricted  with  respect  to 
code  or  grouping  of  bits  except  for  the  packet  formats  specified 
in  3  below. 

See  2.3,4.10  and  2.4.11.3  below  with  regard  to  the  maximum  infor¬ 
mation  field  length. 

2.2.fi  Transparency 

The  DTE  or  DCE,  when  transmitting,  shall  examine  the  frame  con¬ 
tent  between  the  two  flag  sequences  including  the  address,  con¬ 
trol,  Information  and  FCS  sequences  and  shall  insert  a  0  bit 
after  all  sequences  of  5  contiguous  1  bits  (including  the  last  5 
bits  of  the  FCS)  to  ensure  that  a  flag  sequence  is  not  simulated. 
The  DTE  or  DCE,  when  receiving,  shall  examine  the  frame  content 
and  shall  discard  any  0  bit  which  directly  follows  5  contiguous  1 
bits . 


2.2.7  Frame  Checking  Sequence  (FCS) 

The  FCS  shall  be  a  lfi-bit  sequence.  It  shall  be  the  ones  comple¬ 
ment  of  the  sum  (modulo  2)  of: 

1.  The  remainder  of  xk(xl5  ♦  xl4  xl3  +  ...  +  x2  +  x  +  1) 
divided  (modulo  2)  by  the  generator  polynomial 

xl6  +  xl2  +  x5  +  1,  where  k  is  the  number  of  bits  in 
the  frame  existing  between,  but  not  including,  the 
final  bit  of  the  opening  flag  and  the  first  bit  of  the 
FCS,  excluding  bits  inserted  for  transparen-y ,  and 

2.  the  remainder  after  multiplication  by  xlfi  and  then 
division  (modulo  2)  by  the  generator  polynomial 

xl«  +  xl2  +  x5  +  1 ,  of  the  content  of  the  frame,  exist¬ 
ing  between  but  not  including,  the  final  bit  of  the 
opening  flag  and  the  first  bit  of  the  FCS,  excluding 
bits  inserted  for  transparency. 

As  a  typical  implementation,  at  the  transmitter,  the  initial 
remainder  of  the  division  is  preset  to  all  ones  and  is  then  modi¬ 
fied  by  division  by  the  generator  polynomial  (as  described  above) 
on  the  address,  control  and  information  fields;  the  ones  comple¬ 
ment  of  the  resulting  remainder  is  transmitted  as  the  lfi  bit  FCS 
sequence . 
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At  the  receiver,  the  initial  remainder  is  preset  to  all  ones,  and 
the  serial  incoming  protected  bits  and  the  FCS  when  divided  by 
the  generator  polynomial  will  result  in  a  remainder  of 
0001  1101000011  1  1  (  x!5  through  x0,  respectively)  in  the  absence 
of  transmission  errors. 

2.2.P  Order  of  Bit  Transmission 

Addresses,  commands,  responses  and  sequence  numbers  shall  be 
transmitted  with  the  low  order  bit  first  (for  example  the  first 
bit  of  the  sequence  number  that  is  transmitted  shall  have  the 
weight  20) . 

The  order  of  transmitting  bits  within  the  information  field  is 
not  specified  under  2  of  this  Recommendation.  The  FCS  shall  be 
transmitted  to  the  line  commencing  with  the  coefficient  of  the 
highest  term. 


Note:  The  low  order  bit  is  defined  as  bit  1,  as  depicted  in 

Tables  2.1/X.25  to  2.4/X.25. 

2.2.9  Invalid  Frames 


A  frame  not  properly  bounded  by  two  flags,  or  having  fewer  than 
32  bits  between  flags,  is  an  invalid  frame. 

2.2.10  Frame  Abortion 


Aborting  a  frame  is  performed  by  transmitting  at  least  seven  con¬ 
tiguous  Is  (with  no  inserted  Os). 

2.2.11  Interframe  Time  Fill 


Interframe  time  fill  is  accomplished  by  transmitting  contiguous 
flags  between  frames. 

2.2.12  Link  Channel  States 


2.2.12.1  Active  Channel  State 

A  channel  is  in  an  active  condition  when  the  DTE  or  DCE  is 
actively  transmitting  a  frame,  an  abortion  sequence  or  Interframe 
time  fill. 


2.2.12.2  Idle  Channel  State 


A  channel  is  defined  to  be  In  an  idle  condition  when  a  contiguous 
la  state  is  detected  that  persists  for  at  least  IS  bit  times. 


Note  1:  The  action  to  be  taken  upon  detection  of  the  idle  chan¬ 
nel  state  is  a  subject  for  further  study. 


Note  2;  A  link  channel  as  defined  here  is  the  means  of  transmis¬ 
sion  for  one  direction. 

2.3  Elements  of  Procedure 


2.3.1  The  elements  of  procedure  are  defined  in  terms  of  actions 
that  occur  on  receipt  of  commands  at  a  DTE  or  DCE. 

The  elements  of  procedure  specified  below  contain  a  selection  of 
commands  and  responses  relevant  to  the  link  and  system  configura¬ 
tion  described  in  2.1  above. 

A  procedure  is  derived  from  these  elements  of  procedure  and  is 
described  in  2.4  below.  Together  2.2  and  2.3  form  the  general 
requirements  for  the  proper  management  of  the  access  link. 

2.3.2  Control  Field  Formats  and  State  Variables 


2.3.2. 1  Control  Field  Formats 

The  control  field  contains  a  command  or  a  response,  and  sequence 
numbers  where  applicable. 

Three  types  of  control  field  formats  (see  Table  2.2/X.25)  are 
used  to  perform  numbered  information  transfer  (I  frames) ,  num¬ 
bered  supervisory  functions  (S  frames)  and  unnumbered  control 
functions  (U  frames) . 

TABLE  2.2/X.25  -  Control  field  formats 


Control 

field  bits 

1 

2 

3 

4 

5 

00 

r* 

vr 

I 

frame 

0 

N(S) 

P/F 

N(R) 

S 

frame 

1 

0 

S 

S 

P/F 

N(R) 

U 

frame 

1 

1 

M 

M 

P/F 

M  M  M 

N (S )  «  transmitter  send  sequence  number  (bit  2  »  low  order  bit) 

N (R )  •  transmitter  receive  sequence  number  (bit  fi  ■  low  order  bit) 
S  *  supervisory  function  bit 

M  ■  modifier  function  bit 

P/F  *  poll  bit  when  issued  as  a  command,  final  bit  when 
Issued  as  a  response  (1  ■  Poll/Final) 
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Information  transfer  format  -  I 

The  I  format  is  used  to  perform  an  Information  transfer.  The 
functions  of  N(S),  N(R)  and  P/F  are  independent;  i.e.,  each  I 
frame  has  an  N(S),  an  N(R)  which  may  or  may  not  acknowledge  addi¬ 
tional  frames  received  by  the  DTE  or  DCE,  and  a  P/F  bit. 

Supervisory  format  -  S 

The  S  format  is  used  to  perform  link  supervisory  control  func¬ 
tions  such  as  acknowledge  I  frames,  request  retransmission  of  I 
frames,  and  to  request  a  temporary  suspension  of  transmission  of 
I  frames. 

Unnumbered  format  -  U 


The  U  format  is  used  to  provide  additional  link  control  func¬ 
tions.  This  format  contains  no  sequence  numbers.  The  encoding 
of  the  unnumbered  commands  is  as  defined  in  Table  2. 3/X.25. 

2. 3. 2. 2  Control  Field  Parameters 

The  various  parameters  associated  with  the  control  field  formats 
are  described  below. 

2. 3. 2. 3  Modulus 

Each  I  frame  is  sequentially  numbered  and  may  have  the  value  0 
through  modulus  minus  one  (where  "modulus”  is  the  modulus  of  the 
sequence  numbers) .  The  modulus  equals  8  and  the  sequence  numbers 
cycle  through  the  entire  range. 

2. 3. 2. 4  Frame  Variables  and  Sequence  Numbers 
2. 3. 2. 4.1  Send  State  Variable  V(S) 

The  send  state  variable  denotes  the  sequence  number  of  the  next 
in-sequence  I  frame  to  be  transmitted.  The  send  state  variable 
can  take  on  the  value  0  through  modulus  minus  one.  The  value  of 
the  send  state  variable  is  incremented  by  one  with  each  succes¬ 
sive  I  frame  transmission,  but  at  the  DCE  cannot  exceed  N(R)  of 
the  last  received  I  or  S  frame  by  more  than  the  maximum  number  of 
outstanding  I  frames  (k) .  The  value  of  k  is  defined  in  2.4.11.4 
below. 


2.3.2. 4.2  Send  Sequence  Number  N(S) 

Only  I  frames  contain  N(S),  the  send  sequence  number  of  transmit¬ 
ted  frames.  Prior  to  transmission  of  an  in-sequence  I  frame,  the 
value  of  N (S )  is  updated  to  equal  the  value  of  the  send  state 
variable. 
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2 . 3 . 2 .  4 . 3  Receive  State  Variable  V(R) 

The  receive  state  variable  denotes  the  sequence  number  of  the 
next  in-sequence  I  frane  to  be  received.  This  receive  state 
variable  can  take  on  the  values  0  through  modulus  minus  one.  The 
value  of  the  receive  state  variable  is  incremented  by  the  receipt 
of  an  error  free,  in-sequence  !  frame  whose  send  sequence  number 
N  (S )  equals  the  receive  state  variable. 

2. 3. 2. 4. 4  Receive  Sequence  Number  N(R) 

All  I  frames  and  S  frames  contain  N(R),  the  expected  sequence 
number  of  the  next  received  I  frame.  Prior  to  transmission  of  a 
frame  of  the  above  types,  the  value  of  N(R)  is  updated  to  equal 
the  current  value  of  the  receive  state  variable.  N(R)  indicates 
that  the  DTE  or  DCE  transmitting  the  N(R)  has  correctly  received 
all  I  frames  numbered  up  to  and  including  N(R)  -  1. 

2. 3. 3  functions  of  the  Poll/Final  Bit 

The  poll/final  (P/F)  bit  serves  a  function  in  both  command  frames 
and  response  frames.  In  command  frames  the  P/F  bit  is  referred 
to  as  the  P  bit.  In  response  frames  it  is  referred  to  as  the  F 
bit. 

The  use  of  the  P/F  bit  is  described  in  2.4.3  below. 

2.3.4  Commands  and  Responses 

The  following  commands  and  responses  will  be  used  by  either  the 
DTE  or  DCE  and  are  represented  in  Table  2. 3/X.25. 
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TABLE  2.  3/X.25  -  Commands  and  responses 


1  2  3  4  5  A  7  { 


Format 

Conmands 

Responses 

Encoding  ] 

Infornation 
transf er 

T  (information) 

0 

N  (S) 

P 

N  (R)  ' 

< 

Superv isory 

RR  (receive  ready) 

RNR  (receive 
not  ready) 

REJ  (reject) 

RR  (receive  ready) 

RNR  (receive 

not  ready) 

REJ  (reject) 

10  0  0 

10  10 
10  0  1 

P/F 

P/F 

P/F 

N(R) 

N(R)  j 
N(R> 

Unnumbered 

SARM  (set 

asynchronous 
response  mode) 

DM  (disconnected 
mode) 

1111 

P/F 

0  0  C 

SABM  (set 

asynchronous 
balanced  mode) 

1111 

P 

1  0  0 

DISC  (disconnect) 

110  0 

_ 

P 

0  1  0 

UA  (unnumbered 

acknowledge¬ 
ment) 

■ 

1 

1  1  P 

CMDR  (command 
reject) 

FRMR  (frame  reject) 

B 

■ 

Note  It  The  need  for*  end  use  of,  additional  commands  and 
responses  are  for  further  study. 


Note  2s  DTEs  do  not  have  to  implement  both  SARM  and  SABM ;  furth¬ 
ermore  Dm  and  SABM  need  not  be  used  if  SARM  only  is 
used. 

Mote  2*  MR,  RNR  and  REJ  supervisory  command  frames  are  not  used 
—  by  the  DCE  when  SARM  is  used  (LAP). 
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The  commands  and  responses  are  as  follows: 

2. 3. 4.1  Information  (I)  Command 

The  function  of  the  information  (I)  command  is  to  transfer  across 
a  data  link  sequentially  numbered  frames  containing  an  informa¬ 
tion  field. 

2,3.4.?  Receive  Ready  (RR)  Command  and  Response 

The  receive  ready  (RR)  supervisory  frame  is  used  by  the  DTE  or 
DCE  to: 

1)  Indicate  it  is  ready  to  receive  an  I  frame; 

2)  acknowledge  previously  received  I  frames  numbered  up  to 
and  including  N(R)  -  1. 

RR  may  be  used  to  clear  a  busy  condition  that  was  initiated  by 
the  transmission  of  RNR.  The  RR  command  with  the  P  bit  set  to  1 
may  be  used  by  the  DTE  or  DCE  to  ask  for  the  status  of  the  DCE, 
or  DTE,  respectively. 

2. 3. 4. 3  Reject  (REJ)  Command  and  Response 

The  reject  (REJ)  supervisory  frame  is  used  by  the  DTE  or  DCE  to 
request  retransmission  of  I  frames  starting  with  the  frame  num¬ 
bered  N(R).  I  frames  numbered  N  (R )  -  1  and  below  are  ack¬ 
nowledged.  Additional  I  frames  pending  initial  transmission  may 
be  transmitted  following  the  retransmitted  I  frame(s) . 

Only  one  REJ  exception  condition  for  a  given  direction  of  infor¬ 
mation  transfer  may  be  established  at  any  time.  The  REJ  excep¬ 
tion  condition  is  cleared  (reset)  upon  the  receipt  of  an  I  frame 
with  an  N(S)  equal  to  the  N(R)  of  the  REJ.  The  REJ  command  with 
the  P  bit  set  to  1  may  be  used  by  the  DTE  or  DCE  to  ask  for  the 
status  of  the  DCE  or  DTE,  respectively. 

2. 3. 4. 4  Receive  Not  Ready  (RNR)  Command  and  Response 

The  receive  not  ready  (RNR)  supervisory  frame  is  used  by  the  DTE 
or  DCE  to  indicate  a  busy  condition;  i.e.,  temporary  inability  to 
accept  additional  incoming  I  frames.  I  frames  numbered  up  to  and 
including  N (R )  -  1  are  acknowledged.  I  frame  N(R)  and  subsequent 
I  frames  received,  if  any,  are  not  acknowledged;  the  acceptance 
status  of  these  I  frames  will  be  Indicated  in  subsequent 
exchanges . 

An  indication  that  the  busy  condition  has  cleared  is  communicated 
by  the  transmission  of  a  UA,  RR,  REJ  or  SABM.  The  RNR  command 
with  the  P  bit  set  to  1  may  be  used  by  the  DTE  or  DCE  to  ask  for 
the  status  of  the  DCE  or  DTE,  respectively. 
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2 . 3 . 4 . 5  Set  Asynchronous  Response  Mode  (SARK)  Command 

The  SARM  unnumbered  commend  is  used  to  place  the  addressed  DTE  or 
DCE  in  the  asynchronous  response  mode  (ARM)  information  transfer 
phase . 

No  information  field  is  permitted  with  the  SAR*  command.  A  DTE 
or  DCE  confirms  acceptance  of  SARM  by  the  transmission  at  the 
first  opportunity  of  a  UA  response.  Upon  acceptance  of  this  com¬ 
mand  the  DTE  or  DCE  receive  state  variable  V(R)  is  set  to  0. 

Previously  transmitted  I  frames  that  are  unacknowledged  when  this 
command  is  actioned  remain  unacknowledged. 

2.3.4. 6  Set  Asynchronous  Balanced  Mode  (SABM)  Command 

The  SABM  unnumbered  command  is  used  to  place  the  addressed  DTE  or 
DCE  in  the  asynchronous  balanced  mode  (ABM)  information  transfer 
phase . 

No  information  field  is  permitted  with  the  SABM  command.  A  DTE 
or  DCE  confirms  acceptance  of  SABM  by  the  transmission  at  the 
first  opportunity  of  a  UA  response.  Upon  acceptance  of  this  com¬ 
mand  the  DTE  or  DCE  send  state  variable  V(S)  and  receive  state 
variable  V(R)  are  set  to  0. 

Previously  transmitted  I  frames  that  are  unacknowledged  when  this 
command  is  actioned  remain  unacknowledged. 

2. 3. 4. 7  Disconnect  (DISC)  Command 

The  DISC  unnumbered  command  is  used  to  terminate  the  mode  previ¬ 
ously  set.  It  is  used  to  inform  the  DTE  or  DCE  receiving  the 
DISC  that  the  DTE  or  DCE  sending  the  DISC  is  suspending  opera¬ 
tion.  No  Information  field  is  permitted  with  the  DISC  command. 
Prior  to  actioning  the  command ,  the  DTE  or  DCE  receiving  the  DISC 
confirms  the  acceptance  of  DISC  by  the  transmission  of  a  UA 
response.  The  DTE  or  DCE  sending  the  DISC  enters  the  discon¬ 
nected  phase  when  it  receives  the  acknowledging  UA  response. 

Previously  transmitted  I  frames  that  are  unacknowledged  when  this 
command  is  actioned  remain  unacknowledged. 

2. 3. 4. 8  Unnumbered  Acknowledge  (UA)  Response 

The  UA  unnumbered  response  is  used  by  the  DTE  or  DCE  to  ack¬ 
nowledge  the  receipt  and  acceptance  of  the  U  format  commands. 
Received  U  format  commands  are  not  actioned  until  the  UA  response 
is  transmitted.  The  UA  response  is  transmitted  as  directed  by 
the  received  U  format  command.  No  Information  field  is  permitted 
with  the  UA  response. 
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2. 3. 4. 9  Disconnected  Mode  (DM)  Respt  ae 

The  DM  response  is  used  to  report  a  status  where  the  DTE  or  DCE 
is  logically  disconnected  from  the  link,  and  is  in  the  discon¬ 
nected  phase.  The  DM  response  is  sent  in  this  phase  to  request  a 
set  mode  command,  or,  if  sent  in  response  to  the  reception  of  a 
set  mode  command,  to  inform  the  DTE  or  DCE  that  the  DCE  or  DTE, 
respectively,  is  still  in  disconnected  phase  and  cannot  action 
the  set  mode  command.  No  information  field  is  permitted  with  the 
DM  response. 

A  DTE  or  DCE  in  a  disconnected  phase  will  monitor  received  com¬ 
mands,  and  will  react  to  SABM  as  outlined  in  2.4.S  below  and  will 
respond  DM  to  any  other  command  received  with  the  P  bit  set  to  1. 

2.3.4.10  Command  Reject  (CMDR)  Response 
ftrame  Reject  (FRMR )  Response 

The  CMDR  (FRMR)  response  is  used  by  the  DTE  or  DCE  to  report  an 
error  condition  not  recoverable  by  retransmission  of  the  identi¬ 
cal  frame;  l.e.,  one  of  the  following  conditions,  which  results 
from  the  receipt  of  a  frame  without  PCS  error: 

1.  the  receipt  of  a  command  or  response  that  is  invalid  or 
not  Implemented; 

2.  the  receipt  of  an  I  frame  with  an  information  field 
which  exceeds  the  maximum  established  length; 

3.  the  receipt  of  an  invalid  N(R).  (In  the  case  of  LAP, 
see  2. 4. 8.1) 

4.  the  receipt  of  a  frame  with  an  information  field  which 
is  not  permitted  or  the  receipt  of  an  S  or  U  frame  with 
incorrect  length. 

An  Invalid  N  (R )  is  defined  as  one  which  points  to  an  r  frame 
which  has  previously  been  transmitted  and  acknowledged  or  to  an  I 
frame  which  has  not  been  transmitted  and  is  not  the  next  sequen¬ 
tial  I  frame  pending  transmission. 

An  information  field  which  immediately  follows  the  control  field, 
and  consists  of  3  octets,  is  returned  with  this  response  and  pro¬ 
vides  the  reason  for  the  CMDR  (FRMR)  response.  This  format  is 
given  in  Table  2.4/X.2S. 
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TABLE  2.4/X.25  -  CMDR  (FRMR)  information  field  format 
Information  field  bits 


1  2  3  4  5  6  7  8  9  10  1  1  12  13  14  15  1*  17  18  19  20  21  22  23  24 


-  Rejected  frame  control  field  is  the  control  field  of  the 
received  frame  which  caused  the  command  (frame)  reject. 

V (S )  is  the  current  send  state  variable  value  at  the  DTE  or 
DCE  reporting  the  rejection  condition  (bit  10  ■  low  order 
bit)  . 

-  V  (R )  is  the  current  receive  state  variable  value  at  the  DTE 
or  DCE  reporting  the  rejection  condition  (bit  14  «  low  order 
bit)  . 

-  W  set  to  1  Indicates  that  the  control  field  received  and 
returned  in  bits  1  through  8  was  invalid  or  not  implemented. 

-  X  set  to  1  Indicates  that  the  control  field  received  and 
returned  in  bits  1  through  8  was  considered  invalid  because 
the  frame  contained  an  information  field  which  is  not  per¬ 
mitted  or  Is  an  S  or  U  frame  with  Incorrect  length.  Bit  W 
must  be  set  to  1  in  conjunction  with  this  bit. 

-  ¥  set  to  1  indicates  that  the  information  field  received 
exceeded  the  maximum  established  capacity  of  the  DTE  or  DCE 
reporting  the  rejection  condition. 

-  Z  set  to  1  indicates  that  the  control  field  received  and 
returned  in  bits  1  through  8  contained  an  Invalid  N(R). 

Note:  Bits  9,  13,  21  to  24  shall  be  set  to  0  for  CMDR.  For 

FRMR,  bits  9,  21  to  24  shall  be  set  to  0.  Bit  13  shall  be 
set  to  1  if  the  frame  rejected  was  a  response*  and  set  to 
0  if  the  frame  rejected  was  a  command. 
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2.3.5  Exception  Condition  Reporting  and  Recovery 

The  error  recovery  procedures  which  are  available  to  effect 
recovery  followinq  the  detection/occurrence  of  an  exception  con¬ 
dition  at  the  link  level  are  described  below.  Exception  condi¬ 
tions  described  are  those  situations  which  may  occur  as  the 
result  of  transmission  errors,  DTE  or  DCE  malfunction  or  opera¬ 
tional  situations. 

2. 3. 5.1  Busy  Condition 

The  busy  condition  results  when  a  DTE  or  DCE  is  temporarily 
unable  to  continue  to  receive  I  frames  due  to  internal  con¬ 
straints,  e.g.,  receive  buffering  limitations.  In  this  case  an 
RNR  frame  is  transmitted  from  the  busy  DCE  or  DTE.  I  frames 
pending  transmission  may  be  transmitted  from  the  busy  DTE  or  DCE 
prior  to  or  following  the  RNR.  Clearing  of  the  busy  condition  is 
indicated  as  described  in  2. 3. 4. 4  above. 

2.3.  5.  2  N  (S)  Sequence  Error 

The  information  field  of  all  I  frames  whose  N(S)  does  not  equal 
the  receive  state  variable  V(R)  will  be  discarded. 

An  N(S)  sequence  exception  condition  occurs  in  the  receiver  when 
an  I  frame  received  error-free  (no  PCS  error)  contains  an  N(S) 
which  is  not  equal  to  the  receive  state  variable  at  the  receiver. 
The  receiver  does  not  acknowledge  (increment  its  receive  state 
variable)  the  I  frame  causing  the  sequence  error,  or  any  I  frame 
which  may  follow,  until  an  I  frame  with  the  correct  N(S)  is 
received . 

A  DTE  or  DCE  which  receives  one  or  more  I  frames  having  sequence 
errors  but  otherwise  error-free  shall  accept  the  control  informa¬ 
tion  contained  in  the  N(R)  field  and  the  P  bit  to  perform  link 
control  functions;  e.g.,  to  receive  acknowledgement  of  previously 
transmitted  I  frames  and  to  cause  the  DTE  or  DCE  to  respond  (P 
bit  set  to  1).  Therefore,  the  retransmitted  I  frame  may  contain 
an  '•(R)  field  and  P  bit  that  are  updated  from,  and  therefore  dif¬ 
ferent  from,  the  ones  contained  in  the  originally  ti‘uil».sltted  I 
frame. 

2. 3. 5. 3  REJ  Recovery 

The  REJ  is  used  to  initiate  an  exception  recovery  (retransmis¬ 
sion)  following  the  detection  of  a  sequence  error. 

Only  one  asent  REJ"  exception  condition  from  a  DTE  or  DCE  is 
established  at  a  time.  A  sent  REJ  exception  condition  is  cleared 
when  the  requested  I  frame  is  received. 


1 


A  DTE  or  DCE  receiving  REJ  initiates  sequential  ( re-) transmission 
of  I  frames  starting  with  the  I  frame  indicated  by  the  N(R) 


i 

I 


-  A  20  - 


obtained  in  the  REJ  frame. 

2.3. 5.4  Time-out  Recovery 

If  a  DTE  or  DCE,  due  to  a  transmission  error,  does  not  receive 
(or  receives  and  discards)  a  single  I  frame  or  the  last  I  frame 
in  a  sequence  of  I  frames,  it  will  not  detect  an  out-of-sequence 
exception  condition  and  therefore  will  not  transmit  REJ.  The  DTE 
or  DCE  which  transmitted  the  unacknowledged  I  frame(s)  shall, 
following  the  completion  of  a  system  specified  time-out  period 
(see  2.4.11.1  below),  take  appropriate  recovery  action  to  deter¬ 
mine  at  which  I  frame  retransmission  must  begin. 

2. 3. 5. 5  FCS  Error  and  Invalid  Frame 


Any  frame  received  with  an  FCS  error  or  which  is  invalid  (see 
2.2.9  strove)  will  be  discarded  and  no  action  is  taken  as  the 
result  of  that  frame. 

2. 3. 5.8  Rejection  Condition 

A  rejection  condition  is  established  upon  the  receipt  of  an  error 
free  frame  which  contains  an  invalid  command/response  in  the  con¬ 
trol  field,  an  invalid  frame  format,  an  invalid  N  (R )  (however  see 

2. 4. 8.1  below  for  LAP  application)  or  an  information  field  which 
exceeds  the  maximum  information  field  length  which  can  be  accom¬ 
modated. 

At  the  DTE  or  DCE,  this  exception  is  reported  by  a  CM DR  (FRMR) 
response  for  appropriate  DCE  or  DTE  action,  respectively.  Once  a 
DCE  has  established  a  CM DR  (FRMR)  exception,  no  additional  I 
frames  are  accepted,  until  the  condition  is  reset  by  the  DTE, 
except  for  examination  of  the  P  bit  (LAPB)  or  examination  of  the 
P  bit  and  N(R)  (LAP).  The  CMDR  (FRMR)  response  may  be  repeated 
at  each  opportunity  until  recovery  is  effected  by  the  DTE,  or 
until  the  DCE  initiates  its  own  recovery. 

2. 4  Description  of  the  Procedure 

2.4.1  Procedure  to  Set  the  Mode  Variable  B  (Applicable  if  Both 
LAP  and  LAPB  are  Implemented! 

The  DCE  will  maintain  an  internal  mode  variable  B,  which  it  will 
set  as  follows: 

-  to  1,  upon  acceptance  of  an  SABM  command  from  the  DTE 

-  to  0,  upon  acceptance  of  an  SARM  command  from  the  DTE. 

Changes  to  the  mode  variable  B  by  the  DTE  should  occur  only  when 
the  link  has  been  disconnected  as  described  in  2. 4. 4. 3  or  2. 4. 5.3 
below. 
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Should  a  DCE  malfunction  occur,  the  internal  mode  variable  B  will 
upon  restoration  of  operation,  but  prior  to  link  set-up  by  the 
DTE,  be  initially  set  to  1. 

Whenever  P  is  1,  the  DCE  will  use  the  LAPB  link  set-up  and 
disconnection  procedure  and  is  said  to  be  in  the  LAPB  (balanced) 
mode . 

Whenever  B  is  0,  the  DCE  will  use  the  LAP  link  set-up  and  discon¬ 
nection  procedure,  and  is  said  to  be  in  the  LAP  mode. 

The  following  are  applicable  to  both  LAP  and  LAPB  modes:  2.4.2, 
2.4.3,  2.4.6,  2.4.11. 

The  following  are  applicable  only  to  the  LAP  mode:  2.4.4,  2.4.7, 

2  a  *> 

The  following  are  applicable  only  to  the  LAPB  mode:  2.4.5,  2.4.9, 
2.4. 10. 

2.4.2  Procedure  for  Addressing  (Applicable  to  Both  LAP  and  LAPB) 

Frames  containing  commands  transferred  from  the  DCE  to  the  DTE 
will  contain  the  address  A. 

Frames  containing  responses  transferred  from  the  DTE  to  the  DCE 
shall  contain  the  address  A. 

Frames  containing  commands  transferred  from  the  DTE  to  the  DCE 
shall  contain  the  address  B. 

Frames  containing  responses  transferred  from  the  DCE  to  the  DTE 
will  contain  the  address  B. 

A  and  B  addresses  are  coded  as  follows: 

Address  1  2  3  4  5  6  7  fl 

A  11000000 

B  10000000 

Note:  The  DCE  will  discard  all  frames  receive  with  an  address 
other  than  A  or  B;  the  DTE  should  do  the  same. 


2.4.3  Procedure  for  the  Use  of  the  P/F  Bit  (Applicable  to  Both 
LAP  and  LAPB) 


The  DTE  or  DCE  receiving  a  SARM,  SABM,  DISC,  supervisory  command 
or  an  I  frame  with  the  P  bit  set  to  1,  will  set  the  F  bit  to  1  in 
the  next  response  frame  it  transmits. 


The  response  frame  returned  by  the  DCE  to  a  FARM,  SABM  or  DTS0 
command  with  the  P  bit  set  to  1  will  be  a  UA  (or  DM)  response 
with  the  F  bit  set  to  1.  The  response  frame  returned  by  the  DCF 
to  »r  I  frame  with  the  P  bit  set  to  1  will  be  an  RR,  REJ  or  RN’R 
or  CM DR  or  FRMR  response  format  with  the  F  bit  set  to  1. 

The  response  frame  returned  by  the  DCE  to  a  supervisory  command 
frame  with  the  P  bit  set  to  1  will  be  an  RR,  RNR  or  CMDR  or  FRMR 
response  with  the  F  bit  set  to  1. 

The  P  bit  may  be  used  by  the  DCE  in  conjunction  with  the  timer 
recovery  condition  (see  2. 4. 6.8  below). 

Note  Other  use  of  the  P  bit  by  the  DCE  is  a  subject  for  further 
study. 

2.4.4  Procedure  for  Link  Set-up  and  Disconnection  (Applicable  to 
LAP) 

2. 4. 4.1  Link  Set-up 

The  DCE  will  Indicate  that  it  is  able  to  set  up  the  link  by 
transmitting  contiguous  flags  (active  channel  state). 

The  DTE  shall  indicate  a  request  for  setting  up  the  link  by 
transmitting  a  SARM  command  to  the  DCE. 

Whenever  receiving  a  SARM  command,  the  DCE  will  return  a  UA 
response  to  the  DTE  and  set  its  receive  state  variable  V(R)  to  0. 

Should  the  DCE  wish  to  Indicate  a  request  for  setting  up  the 
link,  or  after  transmission  of  a  UA  response  to  a  first  SARM  com¬ 
mand  from  the  DTE  as  a  request  for  setting  up  the  link,  the  DCE 
will  transmit  a  SARM  command  to  the  DTE  and  start  Timer  T1  (see 

2.4.11.1  below).  The  DTE  will  confirm  the  reception  of  the  SARM 
command  by  transmitting  a  UA  response. 

When  receiving  the  UA  response  the  DCE  will  set  its  send  state 
variable  to  o  and  stop  its  Timer  Tl.  If  Timer  T1  runs  out  before 
the  UA  response  is  received  by  the  DCE,  the  DCE  will  retransmit  a 
SARM  command  and  restart  Timer  Tl. 

After  transmission  of  SARM  N2  times  by  the  DCE,  appropriate 
recovery  action  will  be  initiated. 

The  value  of  N2  is  defined  In  2.4.11.2  below. 

2. 4. 4. 2  Information  Transfer  Phase 


After  having  both  received  a  UA  response  to  a  SARM  command 
transmitted  to  the  DTE  and  transmitted  a  UA  response  to  a  SARM 
command  received  from  the  DTE,  the  DCE  will  accept  and  transmit  I 
and  S  frames  according  to  the  procedures  described  in  2.4.6 
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below. 

When  receiving  a  SARM  command,  the  DCE  will  conform  to  the  reset¬ 
ting  procedure  described  in  2.4.7  below.  The  DTE  may  also 
receive  a  SARM  command  according  to  this  resetting  procedure. 

2. 4. 4. 3  Link  Disconnection 

During  the  information  transfer  phase  the  DTE  shall  indicate  a 
request  for  disconnecting  the  link  by  transmitting  a  DISC  command 
to  the  DCE. 

Whenever  receiving  a  DISC  command,  the  DCE  will  return  a  UA 
response  to  the  DTE. 

During  an  information  transfer  phase,  should  the  DCE  wish  to 
indicate  a  request  for  disconnecting  the  link,  or  when  receiving 
from  the  DTE  a  first  DISC  command  as  a  request  for  disconnecting 
the  link,  the  DCE  will  transmit  a  DISC  command  to  the  DTE  and 
start  Timer  T1  (2.4.11.1  below).  The  DTE  will  confirm  reception 
of  the  DISC  command  by  returning  a  UA  response.  After  transmit¬ 
ting  a  SARM  command,  the  DCE  will  not  transmit  a  DISC  command 
until  a  UA  response  is  received  for  this  SARM  command  or  until 
Timer  T1  runs  out. 

When  receiving  a  UA  response  to  the  DISC  command,  the  DCE  will 
stop  its  Timer  Tl.  If  Timer  T1  runs  out  before  a  UA  response  is 
received  by  the  DCE. ,  the  DCE  will  transmit  a  DISC  command  and 
restart  Timer  Tl.  After  transmission  of  DISC  N2  times  by  the 
DCE,  appropriate  recovery  action  will  be  initiated.  The  value  of 
N 2  is  defined  in  2.4.11.2  below. 

2.4.5  Procedures  for  Link  Set-up  and  Disconnection  (Applicable 
to  LAPB ) 


2. 4. 5.1  Link  Set-up 

The  DCE  will  Indicate  that  it  is  able  to  set  up  the  link  by 
transmitting  contiguous  flags  (active  channel  state). 

Whenever  receiving  an  5ABM  command,  the  DCE  will  return  a  UA 
response  to  the  DTE  and  set  both  its  send  and  receive  state  vari¬ 
ables  V(S)  and  V(R)  to  fl. 

Should  the  DCE  wish  to  set-up  the  link,  it  will  send  the  SABM 
coma  and  and  start  Timer  Tl  (see  2.4.11.1  below).  Upon  reception 
of  the  UA  response  from  the  DTE  the  DCE  tesets  both  its  send  and 
receive  state  variables  V(S)  and  V(R)  to  0  and  stops  its  Timer 
Tl. 

Should  Tl  expire  before  reception  of  the  UA.  response  from  the 
DTE,  the  DCE  will  retransmit  the  SABM  command  and  restart  Timer 
Tl.  After  transmission  of  the  SABM  command  N2  times  by  the  DCE, 
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appropriate  recovery  action  will  be  initiated.  The  value  of  N2 
is  defined  in  2.4.11.2  below. 

2. 4. 5. 2  Information  Transfer  Phase 

After  having  transmitted  the  UA  response  to  an  SABM  command  or 
having  received  the  UA  response  to  a  transmitted  SABM  commend, 
the  D^E  will  accept  and  transmit  .1  and  S  frames  according  to  the 
procedures  described  in  2.4.6  below. 

When  receiving  an  SABM  command  while  in  the  information  transfer 
phase,  the  DCE  will  conform  to  the  resetting  procedure  described 
in  2.4.9  below. 

2. 4. 5. 3  Link  Disconnection 


During  the  information  transfer  phase,  the  DTE  shall  indicate 
disconnecting  of  the  link  by  transmitting  a  DISC  command  to  the 
DCE. 

When  receiving  a  DISC  command,  the  DCE  will  return  a  UA  response 
to  the  DTE  and  enter  the  disconnected  phase. 

Should  the  DCE  wish  to  disconnect  the  link,  it  will  send  the  DISC 
command  and  start  Timer  Tl  (see  2.4.11.1  below).  Upon  reception 
of  the  UA  response  from  the  DTE,  the  DCE  will  stop  its  Timer  Tl. 

Should  Timer  Tl  expire  before  reception  of  the  UA  response  from 
the  DTE,  the  DCE  will  retransmit  the  DISC  command  and  restart 
Timer  Tl.  After  transmission  of  the  DISC  command  N2  times  by  the 
DCE,  appropriate  recovery  action  will  be  initiated.  The  value  of 
N 2  is  defined  in  2.4.11.2  below. 

2. 4. 5. 4  Disconnected  Phase 


2. 4. 5. 4.1  After  having  received  a  DISC  command  from  the  DTE  and 
returned  a  UA  response  to  the  DTE,  or  having  received  the  UA 
response  to  a  transmitted  DISC  command,  the  DCE  will  enter  the 
disconnected  phase. 

In  the  disconnected  phase,  the  DCE  may  Initiate  link  set-up.  In 
the  disconnected  phase,  the  DCE  will  react  to  the  receipt  of  an 
SABM  command  as  described  in  2.4.S.1  above  and  will  transmit  a  DM 
response  in  answer  to  a  received  DISC  command. 

When  receiving  any  other  command  frame  with  the  P  bit  set  to  1, 
the  DCE  will  transmit  a  DM  response  with  the  F  bit  set  to  1. 

Other  frames  received  in  the  disconnected  phase  will  be  ignored 
by  the  DCE. 
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2. 4. 5. 4. 2  When  the  DCE  enters  the  d  isconnected  phase  after 
detecting  error  conditions  as  listed  in  2.4.10  below,  or  excep¬ 
tionally  after  recovery  from  an  internal  temporary  malfunction  it 
may  also  indicate  this  by  sending  a  DM  response  rather  than  a 
DISC  command.  In  these  cases,  the  DCE  will  transmit  DM  and  start 
its  Timer  T1  (see  2.4.11.1  below).  If  Timer  T1  runs  out  before 
the  reception  of  an  SABM  or  DISC  command  from  the  DTE,  the  DCE 
will  retransmit  the  DM  response  and  restart  Timer  Tl. 

After  transmission  of  the  DM  response  N2  times,  the  DCE  will 
remain  in  the  disconnected  phase  and  appropriate  recovery  actions 
will  be  initiated.  The  value  of  M2  is  defined  in  2.4.11.2  below. 

2. 4. 5. 5  Collision  of  Unnumbered  Commands 

Collision  situations  shall  be  resolved  in  the  following  way. 

2. 4. 5. 5.1  If  the  sent  and  received  U  commands  are  the  same,  the 
DTE  and  DCE  shall  send  the  l)A  response  at  the  earliest  possible 
opportunity.  The  DCE  shall  enter  the  indicated  phase  after 
receiving  the  UA  response. 

2. *. 5. 5. 2  If  the  sent  and  received  U  commands  are  different,  the 
DTE  and  DCE  shall  enter  the  disconnected  phase  and  issue  a  DM 
response  at  the  earliest  possible  opportunity. 

2. 4. 5. 6  Collision  of  DM  Response  with  SABM  or  DISC  Command 

When  a  DM  response  is  issued  by  the  DCE  as  an  unsolicited 
response  to  request  t  .e  DTE  to  issue  a  mode-setting  command  as 
described  in  2. 4. 5. 4. 2,  a  collision  between  a  SABM  or  DISC  com¬ 
mand  Issued  by  the  DTE  and  the  unsolicited  DM  response  issued  by 
the  DCE  may  occur.  In  order  to  avoid  misinterpretation  of  the  DM 
received,  it  is  suggested  that  the  DTE  always  will  send  its  SABM 
or  DISC  command  with  the  P  bit  set  to  1. 

2. 4. *5  Procedures  for  Information  Transfer  (Applicable  to  Both 
LAP  and  LAPS) 

The  procedures  which  apply  to  the  transmission  of  I  frames  in 
each  direction  during  the  information  transfer  phase  are 
described  below. 

In  the  following,  "number  one  higher*  is  in  reference  to  a  con¬ 
tinuously  repeated  sequence  series,  i.e.,  7  is  one  higher  than  6 
and  0  is  one  higher  than  7  for  modulo  eight  series. 

2. 4. 6.1  Sending  I  Frames 

Wh*n  the  DCE  has  an  I  frame  to  transmit  (i.e.,  an  I  frame  not 
already  transmitted,  or  having  to  be  retransmitted  as  described 
in  2.4.6.S  below),  it  will  transmit  it  with  an  N(S)  equal  to  its 
current  send  state  variable  V(S),  and  an  N(R)  equal  to  its 
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current  receive  state  variable  V(R).  At  the  end  of  the  transmis¬ 
sion  of  the  I  frame,  it  will  increment  its  send  state  variable 
V  (S )  by  one. 

If  the  Timer  T1  is  not  running  at  the  instant  of  transmission  of 
an  I  frame,  it  will  be  started. 

If  the  send  state  variable  V(S)  is  equal  to  the  last  value  of 
N  (R )  received  plus  k  (where  k  is  the  maximum  number  of  outstand¬ 
ing  I  frames  -  see  2.4.11.4  below)  the  DOE  will  not  transmit  any 
new  I  frames,  but  may  retransmit  an  T  frame  as  described  in 
2. 4. 6. 5  or  2.4.6.?  below. 

Note;  In  order  to  ensure  security  of  information  transfer,  the 
DTE  should  not  transmit  any  I  frame  if  its  send  state 
variable  V(S)  is  equal  to  the  last  value  of  N(R)  it  has 
received  from  the  DCE  plus  7. 

When  the  DCE  is  in  the  busy  condition  it  may  still  transmit  I 
frames,  provided  that  the  DTE  is  not  busy  itself.  When  the  DCE 
is  in  the  command  rejection  condition  (LAP),  it  may  still 
transmit  I  frames.  When  the  DCE  is  in  the  frame  rejection  condi¬ 
tion  (LAPB) ,  it  will  stop  transmitting  I  frames. 

2. 4. 6. 2  Receiving  an  I  Frame 

2. 4.6. 2.1  When  the  DCE  is  not  in  a  busy  condition  and  receives 
with  the  correct  PCS  an  I  frame  whose  send  sequence  number  is 
equal  to  the  DCE  receive  state  variable  V(R),  the  DCE  will  accept 
the  information  field  of  this  frame,  increment  by  one  its  receive 
state  variable  V(R),  and  act  as  follows: 

i)  If  an  T  frame  is  available  for  transmission  by  the  DCE, 
it  may  act  as  in  2. 4. 6.1  above  and  acknowledge  the 
received  I  frame  by  setting  N(R)  in  the  control  field 
of  the  next  transmitted  I  frame  to  the  value  of  the  DCE 
receive  state  variable  V(R).  The  DCE  may  also  ack¬ 
nowledge  the  received  I  frame  by  transmitting  an  RR 
with  the  N(R)  equal  to  the  value  of  the  DCE  receive 
state  variable  V(R). 

11)  If  no  I  frame  is  available  for  transmission  by  the  DCE, 
it  will  transmit  an  RR  with  the  N(R)  equal  to  the  value 
of  the  DCE  receive  state  variable  V(R). 

2. 4. 6. 2. 2  When  the  DCE  is  in  a  busy  condition,  it  may  ignore  the 
information  field  contained  in  any  received  I  frame. 

Note;  Zero  length  Information  fields  shall  not  be  passed  to  the 
Packet  Level  and  this  situation  should  be  indicated  to  the 
Packet  Level . 
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2. 4. 6. 3  Reception  of  Incorrect  Frames 

When  the  DCE  receives  a  frame  with  an  incorrect  PCS  or  receives 
an  invalid  frame  (see  2.2.9),  this  frame  will  be  discarded. 

When  the  DCE  receives  an  I  frame  whose  PCS  is  correct,  but  whose 
send  sequence  number  is  incorrect,  i.e.,  not  equal  to  the  current 
DCE  receive  state  variable  V(R),  it  will  discard  the  information 
field  of  the  frame  and  transmit  an  REJ  response  with  the  N (R )  set 
to  one  higher  than  the  N(S)  of  the  last  correctly  received  I 
frame.  The  DCE  will  then  discard  the  Information  field  of  all  I 
frames  until  the  expected  I  frame  is  correctly  received,  when 
receiving  the  expected  I  frame,  the  DCE  will  then  acknowledge  the 
frame  as  described  in  2. 4. 6. 2  above.  The  DCE  will  use  the  N(R) 
and  P  bit  indications  in  the  discarded  I  frames. 

2. 4. 6. 4  Receiving  Acknowledgement 

When  correctly  receiving  an  I  or  S  frame  (RR,  RNR  or  REJ),  even 
in  the  busy  or  command  rejection  condition,  the  DCE  will  consider 
the  N (R )  contained  in  this  frame  as  an  acknowledgement  for  all 
the  I  frames  it  has  transmitted  with  an  N(S)  up  to  and  including 
the  received  N(R)  minus  one.  The  DCE  will  reset  the  Timer  T1 
when  it  correctly  receives  an  I  or  S  frame  with  the  N (R)  higher 
than  the  last  received  N(RJ  (actually  acknowledging  some  I 
frames) . 

If  the  timer  has  been  reset,  and  if  there  are  outstanding  I 
frames  still  unacknowledged,  it  will  restart  the  Timer  Tl.  If 
the  timer  then  runs  out,  the  DCE  will  follow  the  retransmission 
procedure  (in  2.4.A.5  and  2. 4. 6. 8  below)  with  respect  to  the 
unacknowledged  I  frames. 

2. 4. 6. 5  Receiving  Reject 

When  receiving  an  REJ,  and  DCE  will  set  its  send  state  variable 
V(S)  to  the  N(R)  received  in  the  REJ  control  field.  It  will 
transmit  the  corresponding  I  frame  as  soon  as  it  is  available  or 
retransmit  it.  (Re) transmission  will  conform  to  the  following: 

i)  If  the  DCE  is  transmitting  a  supervisory  or  unnumbered 
command  or  response  when  it  receives  the  REJ,  it  will 
complete  that  transmission  before  commencing  transmis¬ 
sion  of  the  requested  I  frame. 

li)  If  the  DCE  is  transmitting  an  I  frame  when  the  REJ  is 
received,  it  may  abort  the  I  frame  and  commence 
transmission  of  the  requested  I  frame  immediately  after 
abortion. 

iii)  If  the  DCE  is  not  transmitting  any  frame  when  the  REJ 
is  received,  it  will  commence  transmission  of  the 
requested  1  frame  immediately. 


In  all  cases.  if  other  unacknowledged  I  frames  had  el  ready  been 
transmitted  following  the  one  indicated  in  the  REJ,  then  those  I 
frames  will  be  r etransmitted  by  the  DCE  following  the  retransmis¬ 
sion  of  the  requested  T  frame. 

If  the  REJ  frame  was  received  from  the  DTE  as  a  command  with  the 
P  bit  set  to  1,  the  DTE  will  transmit  an  RR  or  RNR  response  with 
the  F  bit  set  to  1  before  transmitting  or  retransmitting  the 
corresponding  I  frame. 

2.4.6.*  Receiving  RMR 

After  receiving  an  RNR,  the  DCE  may  transmit  or  retransmit  the  I 
fraii  e  with  the  send  sequence  number  equal  to  the  N  (R )  indicated 
in  the  RNR.  If  the  Timer  T1  runs  out  after  the  reception  of  RNR, 
the  DCE  will  follow  the  procedure  described  in  2. 4. 6.8  below.  In 
any  case  the  DCE  will  not  transmit  any  other  I  frames  before 
receiving  an  RR  or  REJ. 

2. 4. 6. 7  DCE  Busy  Condition 

When  the  DCE  enters  a  busy  condition,  it  will  transmit  an  RNR 
response  at  the  earliest  opportunity.  While  in  the  busy  condi¬ 
tion,  the  DCE  will  accept  and  process  S  frames  and  return  an  RNR 
response  with  the  F  bit  set  to  1  if  it  receives  an  S  or  I  command 
frame  with  the  P  bit  set  to  1.  To  clear  the  busy  condition,  the 
DCE  will  transmit  either  an  REJ  response  or  an  RR  response  with 
N (R )  set  to  the  current  receive  state  variable  V (R J  depending  on 
whether  or  not  it  discarded  information  fields  of  correctly 
received  I  frames. 

Notei  The  DTE  when  encountering  a  DCE  busy  condition,  may  send 
supervisory  command  frames  with  the  P  bit  set  to  1.  In 
the  event  that  the  DTE  has  not  implemented  supervisory 
commands,  it  may  follow  the  procedures  of  the  DCE  (see 
2.4.6.6)  (applicable  to  LAPB). 

2. 4. 6.0  Waiting  Acknowledgement 

The  DCE  maintains  an  internal  retransmission  count  variable  which 
Is  set  to  0  when  the  DCE  receives  a  UA  or  RNR,  or  when  the  DCE 
correctly  receives  an  I  or  S  frame  with  the  N(R)  higher  than  the 
last  received  N(R)  (actually  acknowledging  some  outstanding  I 
frames) . 

If  the  Timer  T1  runs  out,  the  DCE  will  (re-)enter  the  timer 
recovery  condition,  add  one  to  its  retransmission  count  variable 
and  set  an  internal  variable  X  to  the  current  value  of  its  send 
state  variable. 


The  DCE  will  restart  Timer  Tl,  set  its  send  state  variable  to  the 
last  N(R)  received  from  the  DTE  and  retransmit  the  corresponding 
I  frame  with  the  P  bit  set  to  1  (LAP  or  LAPB)  or  transmit  an 
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appropriate  supervisory  command  with  the  P  bit  set  to  1  (LAPS 
only)  . 

The  timer  recovery  condition  is  cleared  when  the  DCE  receives  a 
valid  S  frame  from  the  DTE,  with  the  F  bit  set  to  1. 

If,  while  in  the  timer  recovery  condition,  the  DCE  correctly 
receives  a  supervisory  frame  with  the  F  bit  set  to  1  and  with  the 
N (R )  within  the  range  from  its  current  send  state  variable  to  X 
included,  it  will  clear  the  timer  recovery  condition  and  set  its 
send  state  variable  to  the  received  N(R). 

If,  while  in  the  timer  recovery  condition,  the  DCE  correctly 
receives  a  supervisory  frame  with  the  F  bit  set  to  0  and  with  an 
N(R)  within  the  range  from  its  current  send  state  variable  to  X 
included,  it  will  not  clear  the  timer  recovery  condition.  The 
received  N(R)  may  be  used  to  update  the  send  state  variable. 
However,  the  DCE  may  decide  to  keep  the  last  transmitted  I  frame 
in  store  (even  if  it  is  acknowledged)  in  order  to  be  able  to 
retransmit  it  with  the  P  bit  set  to  l  when  Timer  T1  expires  at  a 
later  time. 

If  the  retransmission  count  variable  is  equal  to  N2,  the  DCE  ini- 
tiates  a  resetting  procedure  for  the  direction  of  transmission 
from  the  DCE  as  described  in  2. 4. 7. 3,  2.4.9. 2  or  2. 4. 9. 3  below. 

N2  is  a  system  parameter  (see  2.4.11.2  below). 

Note:  Although  the  DCE  will  Implement  the  Internal  variable  X, 

other  mechanisms  do  exist  that  achieve  the  identical  func- 
tions.  Therefore,  the  Internal  variable  X  is  not  neces¬ 
sarily  implemented  in  the  DTE. 

2.4.7  Procedures  for  Resetting  (Applicable  to  LAP) 

2. 4. 7.1  The  resetting  procedure  is  used  to  reinitialize  one 
direction  of  information  transmission,  according  to  the  procedure 
described  below.  The  resetting  procedure  only  applies  during  the 
information  transfer  phase. 

2. 4. 7. 2  The  DTE  will  indicate  a  resetting  of  the  information 
transmission  from  the  DTE  by  transmitting  an  SARM  command  to  the 
DCE.  When  receiving  an  SARM  command,  the  DCE  will  return,  at  the 
earliest  opportunity,  a  UA  response  to  the  DTE  and  set  its 
receive  state  variable  V(R)  to  0.  This  also  indicates  a  clear¬ 
ance  of  the  DCE  busy  condition,  if  present. 

2.4.7. 3  The  DCE  will  indicate  a  resetting  of  the  Information 
transmission  from  the  DCE  by  transmitting  an  SARM  command  to  the 
DTE  and  will  start  Timer  T1  (see  2.4.11.1  below).  The  DTE  will 
confirm  reception  of  the  SARM  command  by  returning  a  UA  response 
to  the  DCE.  When  receiving  this  UA  response  to  the  SARM  command, 
the  DCE  will  set  its  send  state  variable  to  0  and  stop  its  Timer 
Tl.  If  Timer  T1  runs  out  before  the  UA  response  is  received  by 
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the  DCE,  the  DCE  will  retransnit  an  RARM  command  and  restart 
Timer  Tl.  After  transmission  of  RAR*  N2  times,  appropriate 
recovery  action  will  he  initiated.  The  value  of  N2  is  defined  in 
2.4.11.2  below. 

The  DCE  will  not  act  on  any  received  response  frame  which  arrives 
before  the  UA  response  to  the  SAR*  command.  The  value  of  N fR ) 
contained  in  any  correctly  received  1  command  frames  arriving 
before  the  UA  response  will  also  be  ignored. 

2. 4. 7. 4  when  receiving  a  r*PR  response  from  the  DTE,  the  DCE 
will  initiate  a  resetting  of  the  information  transmission  from 
the  DCE  as  described  in  2. 4. 7. 3  above. 

2. 4. 7. R  if  the  DCE  transmits  a  CMDR  response,  it  enters  the  com¬ 
mand  rejection  condition.  This  command  rejection  condition  is 
cleared  when  the  DCE  receives  an  SARM  or  DISC  command.  Any  other 
command  received  while  in  the  command  rejection  condition  will 
cause  the  DCE  to  retransmit  this  CMDR  response.  The  coding  of 
the  CM DR  response  will  be  as  described  in  2.3.4.10  above. 

2.4.8  Rejection  Conditions  (Applicable  to  LAP) 

2. 4. 8.1  Rejection  Conditions  Causing  a  Resetting  of  the 
Transmission  of  information from  ttie  t)CE 

The  DCE  will  initiate  a  resetting  procedure  as  described  in 
2. 4. 7. 3  above  when  receiving  a  frame  with  the  correct  PCS,  with 
the  address  A  (coded  11000000)  and  with  one  of  the  follow¬ 
ing  conditions: 

-  the  frame  type  is  unknown  as  one  of  the  responses  used; 

-  the  information  field  is  invalid; 

-  the  N(R)  contained  in  the  control  field  is  invalid; 

-  the  response  contains  an  P  bit  set  to  1  except  during  a 
timer  recovery  condition  as  described  in  2. 4. 6. 8  above. 

The  DCE  will  also  initiate  a  resetting  procedure  as  described  in 
2. 4.7. 3  above  when  receiving  an  I  frame  with  correct  PCS,  with 
the  address  B  (coded  10000000)  and  with  an  invalid  N(R) 
contained  in  the  control  field.  ^ 

A  valid  N(R)  must  be  within  the  range  from  the  lowest  send 
sequence  number  N(S)  of  the  still  unacknowledged  frame(s)  to  the 
current  DCE  send  state  variable  included,  even  if  the  DCE  is  in  a 
rejection  condition,  but  not  if  the  DCE  is  in  the  timer  recovery 
condition  (see  2. 4. 6. 8  above). 


The  DCE  will  enter  the  command  rejection  condition  as  described 
in  2. 4. 7. 5  above  when  receiving  a  frame  with  the  correct  PCS, 
witf  the  address  B  (coded  10000000)  and  with  one  of  the 
following  conditions: 

-  the  frame  type  is  unknown  as  one  of  the  commands  used; 

-  the  Information  field  is  invalid. 


2.4.9  Procedures  for  Resetting  (Applicable  to  LAPB) 

2. 4. 9.1  The  resetting  procedures  are  used  to  initialize  both 
directions  of  Information  transmission  according  to  the  procedure 
described  below.  The  resetting  procedures  only  apply  during  the 
information  transfer  phase. 

2. 4. 9. 2  The  DTE  or  DCE  shall  indicate  a  resetting  by  transmit¬ 
ting  an  SABM  command.  After  receiving  an  SABM  command,  the  DCE 
or  DTE,  respectively,  will  return,  at  the  earliest  opportunity,  a 
UA  response  to  the  DTE  or  DCE,  respectively,  and  reset  its  send 
and  receive  state  variables  V(S)  and  V(R)  to  0.  This  also  clears 
a  DCE  and/or  DTE  busy  condition,  if  present.  Prior  to  initiating 
this  link  resetting  procedure,  the  DTE  or  DCE  may  initiate  a 
disconnect  procedure  as  described  in  2. 4. 5. 3  above. 

2. 4. 9. 3  Under  certain  rejection  conditions  listed  in  2. 4. 6. 8 
above  and  2.4.10.2  below,  the  DCE  may  ask  the  DTE  to  reset  the 
link  by  transmitting  a  DM  response. 

After  transmitting  a  DM  response,  the  DCE  will  enter  the  discon¬ 
nected  phase  as  described  in  2. 4. 5. 4. 2  above. 

2. 4. 9. 4  Under  certain  rejection  conditions  listed  in  2.4.10.1 
below,  the  DCE  may  ask  the  DTE  to  reset  the  link  by  transmitting 
a  FRMR  response. 

After  transmitting  a  FRMR  response,  the  DCE  will  enter  the  frame 
rejection  condition.  The  frame  rejection  condition  is  cleared 
when  the  DCE  receives  an  SABM  or  DISC  command  or  DM  response. 

Any  other  command  received  while  in  the  frame  rejection  condition 
will  cause  the  DCE  to  retransmit  the  FRMR  response  with  the  same 
information  field  as  originally  transmitted. 

The  DCE  may  start  a  Timer  T1  on  transmission  of  the  FRMR 
response.  If  Timer  T1  runs  out  before  the  reception  of  an  SABM 
or  DISC  command  from  the  DTE,  the  DCE  may  retransmit  the  FRMR 
response  and  restart  Timer  Tl.  After  transmission  of  the  FRMR 
response  N2  times  the  DCE  may  reset  the  link  as  described  in 
2. 4. 9. 2  above.  The  value  of  N2  is  defined  in  2.4.11.2  below. 
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2.4.10  Rejection  Conditions  (Applicable  to  LAPB) 

2.4.10.1  The  DCE  will  initiate  a  resetting  procedure  as 
described  in  2. 4. o.4  above,  when  receiving,  during  the  informa¬ 
tion  transfer  phase,  a  frame  with  the  correct  FCS,  with  the 
address  A  or  B,  and  with  one  of  the  following  conditions: 

-  the  frame  is  unknown  as  a  command  or  as  a  response; 

-  the  information  field  is  invalid; 

-  the  N (R )  contained  in  the  control  field  is  invalid  as 
described  in  2.4.B.1  above. 

The  coding  of  the  information  field  of  the  FRMR  response  which  is 
transmitted  is  given  in  2.3.4.10  above.  Bit  13  of  this  informa¬ 
tion  field  is  set  to  0  i f  the  address  of  the  rejected  frame  is  B. 
It  is  set  to  1  i f  the  address  is  A. 

2.4.10.2  The  DCE  will  initiate  a  resetting  procedure  as 
described  in  2. 4. 9. 2  or  2. 4. 9. 3  above  when  receiving  during  the 
information  transfer  phase  a  DM  response  or  a  FRMR  response. 

The  DCE  may  initiate  a  resetting  procedure  as  described  in 

2. 4. 9. 2  or  2. 4. 9. 3  above  when  receiving  during  the  information 
transfer  phase  a  UA  response  or  an  unsolicited  response  with  the 
F  bit  set  to  1. 

2.4.11  List  of  System  Parameters  (Applicable  to  Both  LAP  and 
LAPS) 

The  system  parameters  are  as  follows: 

2.4.1!.1  Timer  T1 

The  period  of  the  Timer  T1  will  take  into  account  whether  the 
timer  is  started  at  the  beginning  or  the  end  of  the  frame  in  the 
DCE. 

The  period  of  the  Timer  Tl,  at  the  end  of  which  retransmission  of 
a  frame  may  be  initiated  according  to  the  procedures  described  in 
2.4.4  to  2.4.6  abtve,  is  a  system  parameter  agreed  for  a  period 
of  time  with  the  Administration. 

The  proper  operation  of  the  procedure  requires  that  Timer  Tl  be 
greater  than  the  maximum  time  between  transmission  of  frames 
(SARM,  SABM,  DM,  DISC,  FRMR,  I  or  supervisory  commands)  and  the 
reception  of  the  corresponding  frame  returned  as  an  answer  to 
this  frame  (UA,  DM  or  acknowledging  frame).  Therefore,  the  DTE 
should  not  delay  the  response  or  acknowledging  frame  returned  to 
the  above  frames  by  more  than  a  value  T2  less  than  Tl,  where  T2 
is  a  system  parameter. 
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The  DCE  will  not  delay  the  response  or  acknowledging  frame 
returned  to  a  command  by  more  than  T2. 

2.4.11.?  Maximum  Number  of  Transmissions  N? 

The  value  of  the  maximum  number  N2  of  transtr. ission  and 
retransmissions  of  a  frame  following  the  running  out  of  Timer  T1 
is  a  system  parameter  agreed  for  a  period  of  time  with  the 
Adadnistration. 

2.4.11.3  Maximum  Number  of  Bits  in  an  I  Frame  Ml 

The  maximum  number  of  bits  in  an  I  frame  is  a  system  parameter 
which  depends  upon  the  maximum  length  of  the  Information  fields 
transferred  across  the  DTE/DCE  interface. 

2.4.11.4  Maximum  Number  of  Outstanding  I  Frames  k 

The  maximum  number  (k)  of  sequentially  numbered  I  frames  that  the 
DTE  or  DCE  may  have  outstanding  (i.e.,  unacknowledged)  at  any 
given  time  is  a  system  parameter  which  can  never  exceed  seven. 

It  shall  be  agreed  for  a  period  of  time  with  the  Administration. 

Mote:  As  a  result  of  the  further  study  proposed  in  2.2.4  above. 

the  permissible  maximum  number  of  outstanding  I  frames  may 
be  Increased. 


3.  DESCRIPTION  OF  THE  PACKET  LEVEL  PTE /DCE  INTERFACE 

This  and  subsequent  sections  of  the  recommendation  relate  to  the 
transfer  of  packets  at  the  DTE/DCE  interface.  The  procedures 
apply  to  packets  which  are  successfully  transferred  across  the 
DTE/DCE  Interface. 

Each  packet  to  be  transferred  across  the  DTE/DCE  Interface  shall 
be  contained  within  the  link  level  information  field  which  will 
delimit  its  length,  and  only  one  packet  shall  be  contained  in  the 
information  field. 


Note  It  Possible  insertion  of  more  than  one  packet  in  the  link 
level  Information  field  is  for  further  study. 

Note  2:  At  present,  some  networks  require  the  data  fields  of 
packets  to  contain  an  integral  number  of  octets.  The 
transmission  by  the  DTE  of  data  fields  not  containing  an 
integral  number  of  octets  to  the  network  may  cause  a 
loss  of  data  integrity. 

Under  urgent  study  are  further  considerations  regarding 
the  trends  of  future  requirements  and  implementations 
toward  either  bit-orientation  (any  number  of  bits)  or 
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oct e t-or 1 en 1 3 1 1  on  ( an  Integral  number  of  octets)  for 
data  fields  in  X. 25  packets. 

PTEs  wishinn  universal  operation  on  all  networks  shoul'’ 
transmit  all  packets  with  data  fields  containing  only  an 
integral  number  of  octets.  Full  data  integrity  can  only 
be  assured  by  exchange  of  octet-oriented  data  fields  in 
both  directions  of  transmission. 

This  section  covers  a  description  of  the  packet  level  interface 
for  virtual  cal  1  ,  permanent  virtual  circuit  an*  datagram  ser¬ 
vices.  As  designated  in  Recommendation  X.2,  virtual  call  and 
permanent  virtual  circuit  services  are  essential  (E)  services  to 
be  provided  by  all  networks.  Datagram  service  is  designated  as 
an  additional  (A)  service  which  may  be  provided  by  some  networks. 

Note :  Under  study  are  considerations  regarding  the  amount  of 

possible  duplication  between  datagram,  fast  select  and 
possible  additional  virtual  call  enhancements  with  the 
objective  to  minimize  the  variety  of  interfaces. 

Procedures  for  virtual  circuit  service  (i.e.,  virtual  call  and 
permanent  virtual  circuit  services)  are  specified  in  section  4. 
Procedures  for  the  datagram  service  are  specified  in  section  5. 

Pac*et  formats  for  all  services  are  specified  in  section  R.  Pro¬ 
cedures  and  formats  for  optional  user  facilities  are  specified  in 
section  7. 

3.1  Logical  Channels 

To  enable  simultaneous  virtual  calls  and/or  permanent  virtual 
circuits  and/or  datagrams,  logical  channels  are  used.  Each  vir¬ 
tual  call,  permanent  virtual  circuit,  and  datagram  channel  is 
assigned  a  Logical  Channel  Group  Number  (less  than  or  equal  to 
15)  and  a  Logical  Channel  Number  (less  than  or  equal  to  255). 

For  virtual  calls,  a  Logical  Channel  Group  Number  and  a  Logical 
Channel  Number  are  assigned  during  the  call  set-up  phase.  The 
range  of  logical  channels  used  for  virtual  calls  is  agreed  with 
the  Administration  at  the  time  of  subscription  to  the  service 
(see  Annex  1).  For  permanent  virtual  circuits  and  datagram  chan¬ 
nels,  Logical  Channel  Group  Numbers  and  Logical  Channel  Numbers 
are  assigned  in  agreement  with  the  Administration  at  the  time  of 
subscription  to  the  service  (see  Annex  1). 

3. 2  Basic  Structure  of  Packets 

Every  packet  transferred  across  the  DTE/DCE  interface  consists  of 
at  least  3  octets.  These  three  octets  contain  a  general  format 
identifier,  a  logical  channel  Identifier  and  a  packet  type  iden¬ 
tifier.  Other  packet  fields  are  appended  as  required  (see  sec¬ 
tion  6 ) . 

Packet  types  and  their  use  in  association  with  various  services 
are  given  in  Table  3.1/X.25. 

I 
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TABLE  3.1/X.25 

PACKET  TYPES  AND  THEIR  USE  IN 
VARIOUS  SERVICES 


PACKET 

TYPE 

SERVICE 

FROM  DCE  TO  DTE 

FROM  DTE  TO  DCE 

VC 

PVC 

DG* 

CALL  SET-UP  AND  CLEARING  (Note  1) 

INCOMING  CALL 

CALL  REQUEST 

X 

CALL  CONNECTED 

CALL  ACCEPTED 

X 

CLEAR  INDICATION 

CLEAR  REQUEST 

X 

DCE  CLEAR  CONFIRMATION 

DTE  CLEAR  CONFIRMATION 

X 

DATA  AND  INTERRUPT  (Note  2) 

DCE  DATA 

DTE  DATA 

X 

X 

DCE  INTERRUPT 

DTE  INTERRUPT 

X 

X 

DCE  INTERRUPT 

DTE  INTERRUPT 

CONFIRMATION 

CONFIRMATION 

X 

X 

DATAGRAM 

(Note  3) 

DCE  DATAGRAM 

DTE  DATAGRAM 

X 

DATAGRAM  SERVICE  SIGNAL 

X 

FLOW  CONTROL  AND 

RESET  (Note  4) 

DCE  RR 

DTE  RR 

X 

X 

X 

DCE  RNR 

DTE  RNR 

X 

X 

X 

DTE  REJ* 

X 

X 

X 

RESET  INDICATION 

RESET  REQUEST 

X 

X 

X 

DCE  RESET  CONFIRMATION 

DTE  RESET  CONFIRMATION 

X 

X 

X 

RESTART  (Note  5) 

RESTART  INDICATION 

RESTART  REQUEST 

X 

X 

X 

DCE  RESTART  CONFIRMATION 

DTE  RESTART  CONFIRMATION 

X 

X 

X 

DIAGNOSTIC 

(Note  6} 

DIAGNOSTIC* 

X 

X 

*  Not  necessarily  available  on  all  networks. 


VC  •  Virtual  call 
PVC  ■  Permanent  virtual  circuit 
DC  ■  Datagram 
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Note 

_1  : 

See  sections  4 
6.2  and  6. P.2 

.1  and  7.2.4  for 
for  formats. 

procedures  and 

sections 

Note 

_2: 

See  section  4. 
mats . 

3  for  procedures 

and 

section  6 . 3 

for 

fo  r- 

Note 

_3: 

See  section  5. 
mats . 

1  for  procedures 

and 

section  6 . 4 

for 

fo  r- 

Note 

_4: 

See  sections  4 
tion  6.5  and  6 

.4,  5.2  and  7.1.4 
.  fl.  1  for  formats. 

for 

procedures 

and 

sec- 

Note 

_5 : 

See  section  3. 
mats . 

3  for  procedures 

and 

section  6.6 

for 

for- 

Note 

_6: 

See  section  3. 
mats . 

4  for  procedures 

and 

section  6.7 

for 

for- 

3. 3  Procedure  for  Restart 

The  restart  procedure  is  used  to  initialize  or  re-initial ize  the 
packet  level  DTE/DCE  interface.  The  restart  procedure  simultane¬ 
ously  clears  all  the  virtual  calls  and  resets  all  the  permanent 
virtual  circuits  and  datagram  channels  at  the  DTE/DCE  interface 
(see  sections  4.5  and  5.3). 

Annex  2,  Figure  A2. 1/X.25  gives  the  state  diagram  which  defines 
the  logical  relationships  of  events  related  to  the  restart  pro¬ 
cedure. 

Annex  3,  Table  A3.2/X.25  specifies  actions  taken  by  the  DCE  on 
the  receipt  of  packets  from  the  DTE  for  the  restart  procedure. 
Details  of  the  action  which  should  be  taken  by  the  DTE  are  for 
further  study. 

3.3.1  Restart  by  the  DTE 

The  DTE  may  at  any  time  request  a  restart  by  transferring  across 
the  DTE/DCE  interface  a  RESTART  REQUEST  packet.  The  interface 
for  each  logical  channel  is  then  in  the  DTE  RESTART  REQUEST  state 
<  r  2 ) . 

The  DCE  will  confirm  the  restart  by  transferring  a  DCE  RESTART 
CONFIRMATION  packet  placing  the  logical  channels  used  for  virtual 
calls  in  the  READY  state  (pi),  and  the  logical  channels  used  for 
permanent  virtual  circuits  and  datagrams  in  the  FLOW  CONTROL 
READY  state  (dl) . 

Notes  States  pi  and  dl  are  specified  in  sections  4  and  5. 

The  DCE  RESTART  CONFIRMATION  packet  can  only  be  interpreted 
universally  as  having  local  significance.  The  time  spent  in  the 
DTE  RESTART  REQUEST  state  ( r 2 )  will  not  exceed  time-limit  T2P 
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(see  Annex  4  )  . 

3. "*.2  Restart  by  the  DCF, 

The  DCE  may  Indicate  a  restart  hy  transferring  across  the  DTE/DCE 
interface  a  RESTART  INDICATION  packet.  The  interface  for  each 
logical  channel  is  then  in  the  DCE  RESTART  INDICATION  state  { r 3 ) . 
In  this  state  of  the  DTE/DCE  interface,  the  DCE  will  ignore  all 
packets  except  for  RESTART  REQUEST  and  DTE  RESTART  CONFIRMATION. 

The  DTE  will  confirm  the  restart  by  transferring  a  DTE  RESTART 
CONFIRMATION  packet  placing  the  logical  channels  used  for  virtual 
calls  in  the  READY  state  (pi),  and  the  logical  channels  used  for 
permanent  virtual  circuits  and  datagrams  in  the  FLOW  CONTROL 
READY  state  (dl ) . 

The  action  taken  by  the  DCE  when  the  DTE  does  not  confirm  the 
restart  within  time-out  T10  is  given  in  Annex  4. 

3.3.3  Restart  Collision 

Restart  collision  occurs  when  &  DTE  and  a  DCE  simultaneously 
transfer  a  RESTART  REQUEST  and  a  RESTART  INDICATION  packet. 

Under  this  circumstance,  the  DCE  will  consider  that  the  restart 
is  completed.  The  DCE  will  not  expect  a  DTE  RESTART  CONFIRMATION 
packet  and  will  not  transfer  a  DCE  RESTART  CONFIRMATION  packet. 
This  places  the  logical  channels  used  for  virtual  calls  in  the 
READY  state  (pi),  and  the  logical  channels  used  for  permanent 
virtual  circuits  and  datagrams  in  the  FLOW  CONTROL  READY  state 
(dM. 


3. 4  Error  Handling 

Table  A3.1/X.25  specifies  the  reaction  of  the  DCE  when  special 
error  conditions  are  encountered.  Other  error  conditions  are 
discussed  in  sections  4  and  5. 

3.4.1  Diagnostic  Packet 

The  DIAGNOSTIC  packet  is  used  by  some  networks  to  indicate  error 
conditions  under  circumstances  when  the  usual  methods  of  indica¬ 
tion  (i.e.,  reset,  clear  and  restart  with  cause  and  diagnostic) 
are  inappropriate  (see  Tables  A3.1/X.25  and  A4.1/X.2S).  The 
DIAGNOSTIC  packet  from  the  DCE  supplies  information  on  error 
situations  which  are  considered  unrecoverable  at  the  packet  level 
of  X. 25;  the  information  provided  permits  an  analysis  of  the 
error  and  recovery  by  higher  levels  at  the  DTE  if  desired  or  pos¬ 
sible. 

A  DIAGNOSTIC  packet  is  issued  only  once  per  particular  instance 
of  an  error  condition.  No  confirmation  is  required  to  be  issued 
by  the  DTE  on  receipt  of  a  DIAGNOSTIC  packet.  After  issuance  of 
a  DIAGNOSTIC  packet,  the  DCE  maintains  the  logical  channel (s)  to 
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which  the  DIAGNOSTIC  packet  is  related  in  the  same  state  as  that 
when  the  DIAGNOSTIC  packet  was  generated. 

3.5 


Changes  of  operational  states  of  the  physical  level  and  the  link 
level  of  the  DTE/DCE  interface  do  not  implicitly  change  the  state 
of  each  logical  channel  at  the  packet  level.  Such  changes  when 
they  occur  are  explicitly  indicated  at  the  packet  level  by  the 
use  of  restart,  clear  or  reset  procedures  as  appropriate. 

A  failure  on  the  physical  and/or  link  level  is  defined  as  a  con¬ 
dition  in  which  the  DCE  cannot  transmit  and  receive  any  frames 
because  of  abnormal  conditions  caused  by,  for  instance,  a  line 
fault  between  DTE  and  DCE. 

Wh»n  a  failure  on  the  physical  and/or  link  level  is  detected, 
virtual  calls  will  be  cleared,  permanent  virtual  circuits  will  be 
declared  out  of  order  and  queued  datagrams  will  be  discarded. 
Further  actions  are  specified  in  section  4.5  for  virtual  circuit 
services  and  in  section  5.4  for  the  datagram  service. 

When  the  failure  is  recovered  on  physical  and  link  levels,  the 
DCE  will  send  a  RESTART  INDICATION  packet  with  the  cause  "Network 
operational"  to  the  local  DTE.  Further  actions  are  specified  in 
section  4.5  for  virtual  circuit  services  and  in  section  5.4  for 
the  datagram  service. 

In  other  out  of  order  conditions  on  the  physical  and/or  link 
level,  including  transmission  of  a  DISC  command  by  the  DTE,  the 
behavior  of  the  DCE  is  for  further  study. 


4.  PROCEDURES  FOR  VIRTUAL  CIRCUIT  SERVICES 
4. 1  Procedures  for  Virtual  Call  Service 

Annex  2,  Figures  A2.1/X.25,  A2.2/X.25  and  A2.3/X.25  show  the 
state  diagrams  which  give  a  definition  of  events  at  the  packet 
level  DTE/DCE  interface  for  each  logical  channel  used  for  virtual 
calls. 

Annex  3  gives  details  of  the  action  taken  by  the  DCE  on  receipt 
of  packets  in  each  state  shown  in  Annex  2.  Details  of  the 
actions  which  should  be  taken  by  the  DTE  are  for  further  study. 

The  call  set-up  and  clearing  procedures  described  in  the  follow¬ 
ing  sections  apply  independently  to  each  logical  channel  assigned 
to  virtual  call  service  at  the  DTE/DCE  interface. 


Effects  of  the  Physical  Level  and  the  Link  Level  on  the 
Packet  Level 
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4.1.1  Ready  State 

If  there  is  no  call  in  existence,  a  logical  channel  is  in  the 
READY  state  (pi ) . 

4.1.2  Call  Request  Packet 

The  calling  DTE  shall  indicate  a  call  request  by  transferring  a 
CALL  REQUEST  packet  across  the  DTE/DCE  interface.  The  logical 
channel  selected  by  the  DTE  is  then  in  the  DTE  WAITING  state 
(p2).  The  CALL  REQUEST  packet  includes  the  called  DTE  address. 
The  calling  DTE  address  field  may  also  be  used. 

Note  1:  A  DTE  address  may  be  a  DTE  network  address,  an  abbrevi- 
ated  address  or  any  other  DTE  identification  agreed  for 
a  period  of  time  between  the  DTE  and  the  DCE. 

Note  2:  The  CALL  REQUEST  packet  should  use  the  logical  channel 
in  the  READY  state  with  the  highest  number  in  the  range 
which  has  been  agreed  with  the  Administration  (see  Annex 
1).  Thus  the  risk  of  call  collision  is  minimized. 

4.1.3  Incoming  Call  Packet 

The  DCE  will  indicate  that  there  is  an  incoming  call  by  transfer¬ 
ring  across  the  DTE/DCE  interface  an  INCOMING  CALL  packet.  This 
places  the  logical  channel  in  the  DCE  WATTING  state  (p3) . 

The  INCOMING  CALL  packet  will  use  the  logical  channel  in  the 
READY  state  with  the  lowest  number  (see  Annex  1).  The  INCOMING 
CALL  packet  includes  the  calling  DTE  address.  The  called  DTE 
address  field  may  also  be  used. 

Note:  A  DTE  address  may  be  a  DTE  network  address,  an  abbrevi¬ 

ated  address  or  any  other  DTE  identification  agreed  for 
a  period  of  time  between  the  DTE  and  the  DCE. 

4.1.4  Call  Accepted  Packet 

The  called  DTE  shall  indicate  its  acceptance  of  the  call  by 
transferring  across  the  DTE/DCE  interface  a  CALL  ACCEPTED  packet 
specifying  the  same  logical  channel  as  that  of  the  INCOMING  CALL 
packet.  This  places  the  specified  logical  channel  in  the  DATA 
TRANSFER  state  (p4). 

If  the  called  DTE  does  not  accept  the  call  by  a  CALL  ACCEPTED 
packet  or  does  not  reject  it  by  a  CLEAR  REQUEST  packet  as 
described  in  section  4.1.7  within  time-out  Til  (see  Annex  4),  the 
DCE  will  consider  it  as  a  procedure  error  from  the  called  DTE  and 
will  clear  the  virtual  call  according  to  the  procedure  described 
in  section  4.1.8. 
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4.1.5  Call  Connected  Packet 

The  receipt  of  a  CALL  CONNECTED  packet  by  the  calling  DTE  speci¬ 
fying  the  same  logical  channel  as  that  specified  in  the  CALL 
REQUEST  packet  indicates  that  the  call  has  been  accepted  by  th« 
called  DTE  by  means  of  a  CALL  ACCEPTED  packet.  This  places  the 
specified  logical  channel  in  the  DATA  TRANSFER  state  (p<). 

The  time  spent  in  the  DTE  WAITING  state  (p2)  will  not  exceed 
time-limit  T21  (see  Annex  4). 

4.1. A  Call  Collision 

Call  collision  occurs  when  a  DTE  and  DCE  simultaneously  transfer 
a  CALL  REQUEST  packet  and  an  INCOMING  CALL  packet  specifying  the 
same  logical  channel.  The  DCE  will  proceed  with  the  call  request 
and  cancel  the  incoming  call. 

4.1.7  Clearing  by  the  DTE 

At  *.ny  time  the  DTE  may  indicate  clearing  by  transferring  across 
the  DTE /DCE  interface  a  CLEAR  REQUEST  packet  (see  section  4.5). 
The  logical  channel  is  then  in  the  DTE  CLEAR  REQUEST  state  (pfi). 
When  the  DCE  is  prepared  to  free  the  logical  channel,  the  DCE 
will  transfer  across  the  DTE/DCE  interface  a  DCE  CLEAR  CONFIRMA¬ 
TION  packet  specifying  the  logical  channel.  The  logical  channel 
is  now  in  the  READY  state  (pi). 

The  DCE  CLEAR  CONFIRMATION  packet  can  only  be  interpreted  univer¬ 
sally  as  having  local  significance,  however  within  some 
Administration's  networks  clear  confirmation  may  have  end  to  end 
significance.  In  all  cases  the  time  spent  in  the  DTE  CLEAR 
REQUEST  state  (p6)  will  not  exceed  time-limit  T23  (see  Annex  4). 

It  is  possible  that  subsequent  to  transferring  a  CLEAR  REQUEST 
packet  the  DTE  will  receive  other  types  of  packets,  dependent  on 
the  state  of  the  logical  channel,  before  receiving  a  DCE  CLEAR 
CONFIRMATION  packet. 

Note:  The  calling  DTE  may  abort  a  call  by  clearing  it  before 

it  has  received  a  CALL  CONNECTED  or  CLEAR  INDICATION 
packet . 

The  called  DTE  may  refuse  an  incoming  call  by  clearing  it  as 
described  in  this  section  rather  than  transmitting  a  CALL 
ACCEPTED  packet  as  described  in  section  4.1.4. 

4.1.8  Clearing  by  the  DCE 

The  DCE  will  indicate  clearing  by  transferring  across  the  DTE/DCE 
Interface  a  CLEAR  INDICATION  packet  (see  section  4.5).  The  logi¬ 
cal  channel  is  then  in  the  DCE  CLEAR  INDICATION  state  (p7).  The 
DTE  shall  respond  by  transferring  across  the  DTE/DCE  interface  a 


t 


j  * 

I  ; 
K 


41 


DTE  CLEAR  CONFIRMATION  packet.  The  logical  channel  is  now  in  the 
READY  state  (pi). 

The  action  taken  by  the  DCE  when  the  DTE  does  not  confirm  clear¬ 
ing  within  time-out  T13  is  given  in  Annex  4. 

4.1.9  Clear  Collision 

Clear  collision  occurs  when  a  DTE  and  a  DCE  simultaneously 
transfer  a  CLEAR  REQUEST  packet  and  a  CLEAR  INDICATION  packet 
specifying  the  same  logical  channel.  Under  this  circumstance  the 
DCE  will  consider  that  the  clearing  is  completed.  The  DCE  will 
not  expect  a  DTE  CLEAR  CONFIRMATION  packet  and  will  not  transfer 
a  DCE  CLEAR  CONFIRMATION  packet.  This  places  the  logical  channel 
in  the  READY  state  (pi). 

4.1.10  Unsuccessful  Call 

If  a  call  cannot  be  established,  the  DCE  will  transfer  a  CLEAR 
INDICATION  packet  specifying  the  logical  channel  indicated  in  the 
CALL  REQUEST  packet. 

4.1.11  Call  Progress  Signals 

The  DCE  will  be  capable  of  transferring  to  the  DTE  clearing  call 
progress  signals  as  specified  in  Recommendation  X.9fi. 

Clearing  call  progress  signals  will  be  carried  in  CLEAR  INDICA¬ 
TION  packets  which  will  terminate  the  call  to  which  the  packet 
refers.  The  method  of  coding  CLEAR  INDICATION  packets  containing 
call  progress  signals  is  detailed  in  section  R.2.3. 

4.1.12  Data  Transfer  State 

The  procedures  for  the  control  of  packets  between  DTE  and  DCE 
while  in  the  DATA  TRANSFER  state  are  contained  in  section  4.3. 

4. 2  Procedures  for  Permanent  Virtual  Circuit  Service 

Annex  2,  Figures  A2.1/X.25  and  A2.3/X.25  show  the  state  diagrams 
which  give  a  definition  of  events  at  the  packet  level  DTE/DCE 
interface  for  logical  channels  assigned  for  permanent  virtual 
circuits. 

Annex  3  gives  details  of  the  action  taken  by  the  DCE  on  receipt 
of  packets  in  each  state  shown  in  Annex  2.  Details  of  the  action 
which  should  be  taken  by  the  DTE  are  for  further  study. 

For  permanent  virtual  circuits  there  is  no  call  set-up  or  clear¬ 
ing.  The  procedures  for  the  control  of  packets  between  DTE  and 
DCE  while  i  n  thtr  DATA  TRANSFER  state  are  contained  in  section 
4.3. 
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4 . 3  Procedures  for  Data  and  Interrupt  Transfer 

The  data  transfer  and  interrupt  procedures  described  in  the  fol¬ 
lowing  subsections  apply  independently  to  each  logical  channel 
assigned  for  virtual  calls  or  a  permanent  virtual  circuit  exist¬ 
ing  at  the  DTE/DCE  interface. 

Noma]  network  operation  dictates  that  user  data  in  data  and 
interrupt  packets  are  all  passed  transparently,  unaltered  through 
the  network  in  the  case  of  packet  DTE  to  packet  DTE  communica¬ 
tions.  Order  of  bits  in  data  packets  is  preserved.  Packet 
sequences  are  delivered  as  complete  packet  sequences.  DTE  Diag¬ 
nostic  Codes  are  treated  as  described  in  sections  6.2.3,  6.5.3 
and  6.6.1. 

4.3.1  States  for  Data  Transfer 

A  virtual  call  logical  channel  is  in  the  DATA  TRANSFER  state  (p4) 
after  completion  of  call  establishment  and  prior  to  a  clearing  or 
a  restart  procedure.  A  permanent  virtual  circuit  logical  channel 
is  continually  in  the  DATA  TRANSFER  state  (p4)  except  during  the 
restart  procedure.  Data,  interrupt,  flow  control  and  reset  pack¬ 
ets  may  be  transmitted  and  received  by  a  DTE  in  the  DATA  TRANSFER 
state  of  a  logical  channel  at  the  DTE/DCE  interface.  In  this 
state,  the  flow  control  and  reset  procedures  described  in  section 

4.4  apply  to  data  transmission  on  that  logical  channel  to  and 
from  the  DTE. 

When  a  virtual  call  is  cleared,  data  and  interrupt  packets  may  be 
discarded  by  the  network  (see  section  4.5).  In  addition  data, 
interrupt,  flow  control  and  reset  packets  transmitted  by  a  DTE 
will  be  Ignored  by  the  DCE  when  the  logical  channel  is  in  the  DCE 
CLEAR  INDICATION  state  (p7).  Hence  it  is  left  to  the  DTE  to 
define  DTE  to  DTE  protocols  able  to  cope  with  the  various  possi¬ 
ble  situations  that  may  occur. 

4.3.2  User  Data  Field  Length  of  Data  Packets 

The  standard  maximum  User  Data  field  length  is  128  octets. 

In  addition,  other  maximum  User  Data  field  lengths  may  be  offered 
by  Administrations  from  the  following  list:  16,  32,  64,  256,  512 
and  1024  octets.  An  optional  maximum  User  Data  field  length  may 
be  selected  for  a  period  of  time  as  the  default  maximum  User  Data 
field  length  common  to  all  virtual  calls  at  the  DTE/DCE  Interface 
(see  section  7.2.1).  A  value  other  than  the  default  may  be 
selected  for  a  period  of  time  for  each  permanent  virtual  circuit 
(see  section  7.2.1).  Negotiation  of  maximum  User  Data  field 
lengths  on  a  per  call  basis  may  be  made  with  the  Flow  Control 
Parameter  Negotiation  facility  (see  section  7.2.2). 

The  User  Data  field  of  data  packets  transmitted  by  a  DTE  or  DCE 
may  contain  any  number  of  bits  up  to  the  agreed  maximum. 
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Note :  At  present,  some  networks  require  the  User  Data  field  to 
contain  an  integral  number  of  octets  (see  section  3,  Note 
2) . 

If  the  User  Data  field  in  a  data  packet  exceeds  the  locally  per- 
mitted  maximum  User  Data  field  length,  then  the  DCE  will  reset 
the  virtual  call  or  permanent  virtual  circuit  with  the  resetting 
cause  "Local  procedure  error", 

4.3.3  Delivery  Confirmation  Bit 

The  setting  of  the  Delivery  Confirmation  bit  (D  bit)  is  used  to 
indicate  whether  or  not  the  DTE  wishes  to  receive  an  end-to-end 
acknowledgment  of  delivery,  for  data  it  is  transmitting,  by  means 
of  the  packet  receive  sequence  number  P(R)  (see  section  4.4). 

Note  1:  The  use  of  the  D  bit  procedure  does  not  obviate  the  need 
for  a  higher  level  protocol  agreed  between  the  communi¬ 
cating  DTEs  which  may  be  used  with  or  without  the  D  bit 
procedure  to  recover  from  user  or  network  generated 
resets  and  clearings. 

Note  2:  After  January  1982,  the  D  bit  procedure  should  be  con¬ 
sidered  an  integral  part  of  this  Recommendation.  In  the 
interim  period,  the  D  bit  procedure  will  be  available  on 
some  Public  Data  Networks  and  between  some  pairs  of  Pub¬ 
lic  Data  Networks  on  a  bilateral  basis. 

During  the  interim  period.  Administrations  of  networks 
which  do  not  provide  the  D  bit  procedure  should  be  con¬ 
sulted  to  determine  whether  the  significance  of  PfR)  is 
a  local  updating  of  the  window  across  the  packet  level 
DTE/DCE  interface  or  conveys  an  end-to-end  acknowledge¬ 
ment  of  delivery  of  data. 

In  order  to  facilitate  the  orderly  introduction  of  the  D  bit  pro¬ 
cedures  in  DTEs  and  DCEs ,  the . fo 1 1 owi ng  mechanisms  are  provided. 

The  calling  DTE  can  ascertain  during  call  establishment  that  the 
D  bit  procedure  can  be  used  for  the  call  by  setting  bit  7  in  the 
General  Format  Identifier  of  the  CALL  REQUEST  packet  to  1  (see 
section  8.1.1).  Every  network  or  part  of  international  network 
where  the  D  bit  procedure  is  available  will  pass  this  bit  tran¬ 
sparently.  If  the  remote  DTE  is  able  to  handle  the  D  bit  pro¬ 
cedure,  it  should  not  regard  this  bit  being  set  to  1  in  the 
INCOMING  CALL  packet  as  invalid. 

Likewise,  the  called  DTE  can  set  bit  7  in  the  General  Format 
Identifier  of  the  CALL  ACCEPTED  packet  to  1.  Every  network  or 
part  of  international  network  where  the  D  bit  is  available  will 
pass  this  bit  transparently.  If  the  calling  DTE  is  able  to  han¬ 
dle  the  D  bit  procedure,  it  should  not  regard  this  bit  being  set 
to  1 *in  the  CALL  CONNECTED  packet  as  invalid. 


If  ary  network  along  the  path  does  not  support  the  D  bit  pro¬ 
cedure,  this  would  be  indicated  by  call  clearing  by  the  DCE  with 
a  cause  indicating  "Incompatible  destination"  and  the  diagnostic 
"Invalid  general  format  identifier"  or  by  any  other  means  to 
indicate  an  invalid  general  format  identifier  at  a  DTE/DCE  inter¬ 
face  (see  Table  A3.1/X.25). 

The  use  by  the  DTEs  of  the  above  mechanism  in  the  CALL  REQUEST 
and  CALL  ACCEPTED  packets  is  recommended  but  is  not  mandatory  for 
using  the  D  bit  procedure  during  the  virtual  call. 

If  a  D  bit  is  set  to  1  in  a  data  packet  on  a  virtual  call  or  per¬ 
manent  virtual  circuit  where  the  D  bit  is  not  available,  this 
will  be  indicated  to  both  DTEs  by  a  RESET  INDICATION  packet  with 
the  cause  "Incompatible  destination”  and  the  diagnostic  "Invalid 
general  format  identifier",  or  by  any  other  means  to  indicate  an 
invalid  general  format  identifier  at  a  DTE/DCE  interface  (see 
Table  A3.1/X.25). 

4.3.4  Wore  Data  Mark 

If  a  DTE  or  DCE  wishes  to  indicate  a  sequence  of  more  than  one 
packet,  it  uses  a  Wore  Data  mark  (W  bit)  as  defined  below. 

The  w  bit  can  be  set  to  1  in  any  data  packet.  When  it  is  set  to 
1  in  a  full  data  packet  or  in  a  partially  full  data  packet  also 
carrying  the  D  bit  set  to  1,  it  indicates  that  more  data  is  to 
follow.  Recombination  with  the  following  data  packet  may  be  only 
performed  within  the  network  when  the  W  bit  is  set  to  1  in  a  full 
data  packet  which  also  has  the  D  bit  set  to  0. 

A  sequence  of  data  packets  with  every  M  bit  set  to  1  except  for 
the  last  one  will  be  delivered  as  a  sequence  of  data  packets  with 
the  W  bit  set  to  1  except  for  the  last  one  when  the  original 
packets  having  the  W  bit  set  to  1  are  either  full  (irrespective 
of  the  setting  of  the  D  bit)  or  partially  full  but  have  the  D  bit 
set  to  1. 

Two  categories  of  data  packets,  A  and  B,  have  been  defined  as 
shown  in  Table  4.1/X.25.  Table  4.1/X.25  also  illustrates  the 
network's  treatment  of  the  W  and  D  bits  at  both  ends  of  a  virtual 
call  or  permanent  virtual  circuit. 
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TABLE  4.  1  /X .  ? 5 

DEFINITION  OF  TWO  CATEGORIES  OF  DATA  PACKETS 
AND  NETWORK  TREATMENT  OF  THE  M  and  D  BITS 


Data  Packet 

Sent  by 

Source  DTE 

Combining 
wi  th 

Subsequent 
Packet(s)  is 
Performed  by 
the  Network 
when  Possible 

Data  Packet* 
Received  by 
Destination  DTE 

Category 

M 

D 

Full 

M 

D 

B 

0  or  1 

n 

No 

No 

0 

0 

B 

0 

l 

No 

No 

0 

1 

B 

l 

l 

No 

No 

1 

1 

B 

0 

0 

Yes 

No 

0 

0 

B 

0 

1 

Yes 

No 

0 

1 

A 

1 

0 

Yes 

Yes  (see  Note) 

1 

0 

B 

1 

1 

Yes 

No 

1 

1 

*  Refers  to  the  delivered  data  packet  whose  last  bit  of  user  data 
corresponds  to  the  last  bit  of  user  data,  if  any,  that  was 
present  in  the  data  packet  sent  by  the  source  DTE. 


Note:  If  the  data  packet  sent  by  the  source  DTE  is  combined  with 

other  packets,  up  to  and  including  a  category  B  packet, 
the  M  and  D  bit  settings  in  the  data  packet  received  by 
the  destination  DTE  will  be  according  to  that  given  in  the 
two  right  hand  columns  for  the  last  data  packet  sent  by 
the  source  DTE  that  was  part  of  the  combination. 

4.3.5  Complete  Packet  Sequence 

A  complete  packet  sequence  is  defined  as  being  composed  of  a  sin¬ 
gle  category  B  packet  and  all  contiguous  preceeding  category  A 
packets  (if  any).  Category  A  packets  have  the  exact  maximum  User 
Data  field  length  with  the  M  bit  set  to  1  and  the  D  bit  set  to  0. 
All  other  data  packets  are  category  B  packets. 

When  transmitted  by  a  source  DTE,  a  complete  packet  sequence  is 
always  delivered  to  the  destination  DTE  as  a  single  complete 
packet  sequence. 


Thus,  if  the  receiving  end  has  a  larger  maximum  data  field  length 
than  the  transnittina  end,  then  packets  within  a  complete  packet 
sequence  will  be  combined  within  the  network.  They  will  be 
delivere-5  in  a  complete  packet  sequence  where  each  packet,  except 
the  last  one,  has  the  exact  maximum  data  field  length,  the  M  bit 
set  to  1,  and  the  D  bit  set  to  0.  The  User  Data  field  of  the 
last  packet  of  the  sequence  may  have  less  than  the  maximum  length 
and  the  M  and  P  bits  are  set  as  described  in  Table  4.1/X.25. 

If  the  maximum  data  field  length  is  the  same  at  both  ends,  then 
data  fields  of  data  packets  are  delivered  to  the  receiving  DTP 
exactly  as  they  have  been  received  by  the  network,  except  as  fol¬ 
lows.  If  a  full  packet  with  the  M  bit  set  to  1  and  the  D  bit  set 
to  o  is  followed  by  an  empty  packet,  then  the  two  packets  may  be 
merged  so  as  to  become  a  single  category  B  full  packet.  If  the 
last  packet  of  a  complete  packet  sequence  transmitted  by  the 
source  DTE  has  a  User  Data  field  less  than  the  maximum  length 
with  the  M  bit  set  to  1  and  the  D  bit  set  to  0,  then  the  last 
packet  of  the  complete  packet  sequence  delivered  to  the  receiving 
DTE  will  have  the  M  bit  set  to  n. 

If  the  receiving  end  has  a  smaller  maximum  data  field  length  than 
the  transmitting  end,  then  packets  will  be  segmented  within  the 
network,  and  the  M  and  D  bits  set  by  the  network  as  described  to 
maintain  complete  packet  sequences. 

4.3.6  Qualifier  Bit 

A  complete  packet  sequence  may  be  on  one  of  two  levels.  If  a  DTE 
wishes  to  transmit  data  on  more  than  one  level,  it  uses  an  indi¬ 
cator  called  the  Qualifier  bit  (Q  bit). 

When  only  one  level  of  data  is  being  transmitted  on  a  logical 
channel,  the  Qualifier  bit  is  always  set  to  0.  If  two  levels  of 
data  are  being  transmitted,  the  transmitting  DTE  should  set  the 
Qualifier  bit  in  all  data  packets  of  a  complete  packet  sequence 
to  the  same  value,  either  0  or  1.  A  complete  packet  sequence, 
which  is  transmitted  with  the  Qualifier  bit  set  to  the  same  value 
in  all  packets,  is  delivered  by  the  network  as  a  complete  packet 
sequence  with  the  Qualifier  bit  set  in  all  packets  to  the  value 
assigned  by  the  transmitting  DTE. 

The  action  of  the  network  when  the  Qualifier  bit  is  not  set  to 
the  same  value  by  the  transmitting  DTE  within  a  complete  packet 
sequence  is  left  for  further  study. 

Recommendation  X. 29  gives  an  example  of  the  procedures  to  be  used 
when  the  Qualifier  bit  is  set  to  1. 

Packets  are  numbered  consecutively  (see  section  4. 4. 1.1)  regard¬ 
less  of  their  data  level. 


4.3.7  Interrupt  Procedure 


The  interrupt  procedure  allows  a  DTE  to  transmit  data  to  the 
reiT.ote  DTE,  without  following  the  flow  control  procedure  applying 
to  data  packets  (see  section  4.4).  The  interrupt  procedure  can 
only  apply  in  the  FLOW  CONTROL  READY  state  (dl)  within  the  DATA 
TRANSFER  state  (p4) . 

The  interrupt  procedure  has  no  effect  on  the  transfer  and  flow 
control  procedures  applying  to  the  data  packets  on  the  virtual 
call  or  permanent  virtual  circuit. 

To  transmit  an  Interrupt,  a  DTE  transfers  across  the  DTE/DCE 
interface  a  DTE  INTERRUPT  packet.  The  DTE  should  not  transmit  a 
second  DTE  INTERRUPT  packet  until  the  first  one  is  confirmed  with 
a  DCE  INTERRUPT  CONFIRMATION  packet  (see  Note  2  to  Table 
A3.4/X.25).  The  DCE,  after  the  interrupt  procedure  is  completed 
at  the  remote  end,  will  confirm  the  receipt  of  the  interrupt  by 
transferring  a  DCE  INTERRUPT  CONFIRMATION  packet.  The  receipt  of 
a  DCE  INTERRUPT  CONFIRMATION  packet  indicates  that  the  interrupt 
has  been  confirmed  by  the  remote  DTE  by  means  of  a  DTE  INTERRUPT 
CONFIRMATION  packet. 

The  DCE  indicates  an  Interrupt  from  the  remote  DTE  by  transfer¬ 
ring  across  the  DTE/DCE  interface  a  DCE  INTERRUPT  packet  contain¬ 
ing  the  same  data  field  as  in  the  DTE  INTERRUPT  packet  transmit¬ 
ted  by  the  remote  DTE.  A  DCE  INTERRUPT  packet  is  delivered  at  or 
before  the  point  in  the  stream  of  data  packets  at  which  the  DTE 
INTERRUPT  packet  was  generated.  The  DTE  will  confirm  the  receipt 
of  the  DCE  INTERRUPT  packet  by  transferring  a  DTE  INTERRUPT  CON¬ 
FIRMATION  packet. 

4. 4  Procedures  for  Flow  Control 

This  subsection  only  applies  to  the  DATA  TRANSFER  state  (p4)  and 
specifies  the  procedures  covering  flow  control  of  data  packets 
and  reset  on  each  logical  channel  used  for  a  virtual  call  or  a 
permanent  virtual  circuit. 

4.4.1  Flow  Control 

At  the  DTE/DCE  interface  of  a  logical  channel  used  for  a  virtual 
call  or  permanent  virtual  circuit,  the  transmission  of  data  pack¬ 
ets  is  controlled  separately  for  each  direction  and  is  based  on 
authorizations  from  the  receiver. 

On  a  virtual  call  or  permanent  virtual  circuit,  flow  control  also 
allows  a  DTE  to  limit  the  rate  at  which  the  remote  DTE  can 
transmit  data  packets.  This  is  achieved  by  the  receiving  DTE 
controlling  the  rate  at  which  it  accepts  packets  across  the 
DTE/DCE  interface,  noting  tha-  there  i^  a  network-dependent  limit 
on  the  number  of  data  packetr  which  ./  be  in  the  network  on  the 
virtual  call  or  permanent  virtu*  c..cuit. 


4. 4.  1.1 


Numbering  of  Data  Packets 


Each  data  packet  transmitted  at  the  DTE/DCE  interface  for  each 
direction  of  transmission  in  a  virtual  call  or  permanent  virtual 
circuit  is  sequentially  numbered. 

The  sequence  numbering  scheme  of  the  packets  is  performed  modulo 
8.  The  packet  sequence  numbers  cycle  through  the  entire  range  0 
to  i .  Some  Administrations  will  provide  the  Extended  Packet 
Sequence  Numbering  facility  (see  section  7.1.1)  which,  if 
selected,  provides  a  sequence  numbering  scheme  for  packets  being 
performed  modulo  128.  In  this  ease,  packet  sequence  numbers 
cycle  through  the  entire  range  0  to  127.  The  packet  sequence 
numbering  scheme,  modulo  8  or  128,  is  the  same  for  both  direc¬ 
tions  of  transmission  and  is  common  for  all  logical  channels  at 
the  DTE/DCE  interface. 

Only  data  packets  contain  this  sequence  number  called  the  packet 
send  sequence  number  P(S). 

The  first  data  packet  to  be  transmitted  across  the  DTE/DCE  inter¬ 
face  for  a  given  direction  of  data  transmission,  when  the  logical 
channel  has  just  entered  the  FLOW  CONTROL  READY  state  (dl),  has  a 
packet  send  sequence  number  equal  to  0. 

4. 4. 1.2  Window  Description 

At  the  DTE/DCE  interface  of  a  logical  channel  used  for  a  virtual 
call  or  permanent  virtual  circuit  and  for  each  direction  of  data 
transmission,  a  window  is  defined  as  the  ordered  set  of  W  con¬ 
secutive  packet  send  sequence  numbers  of  the  data  packets  author¬ 
ized  to  cross  the  interface. 

The  lowest  sequence  number  in  the  window  is  referred  to  as  the 
lower  window  edge.  When  a  virtual  call  or  permanent  virtual  cir¬ 
cuit  at  the  DTE/DCE  interface  has  just  entered  the  FLOW  CONTROL 
READY  state  (dl),  the  window  related  to  each  direction  of  data 
transmission  has  a  lower  window  edge  equal  to  0. 

The  packet  send  sequence  number  of  the  first  data  packet  not 
authorized  to  cross  the  interface  is  the  value  of  the  lower  win¬ 
dow  edge  plus  W  (modulo  8,  or  128  when  extended). 

The  standard  window  size  W  is  2  for  each  direction  of  data 
transmission  at  the  DTE/DCE  Interface.  In  addition,  other  window 
sizes  may  be  offered  by  Administrations.  An  optional  window  size 
may  be  selected  for  a  period  of  time  as  the  default  window  size 
common  to  all  virtual  calls  at  the  DTE/DCE  Interface  (see  section 
7.1.2).  A  value  other  than  the  default  may  be  selected  for  a 
period  of  time  for  each  permanent  virtual  circuit  (see  section 
7.1.2).  Negotiation  of  window  sizes  on  a  per  call  basis  may  be 
made  with  the  Flow  Control  Parameter  Negotiation  facility  (see 
section  7. 2. 2) . 
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4.4. 1.3  Flow  Control  Principles 

When  the  sequence  number  P(S)  of  the  next  packet  to  be  transmit¬ 
ted  by  the  DCF  is  within  the  window,  the  DCE  is  authorized  to 
transmit  this  data  packet  to  the  DTE.  When  the  sequence  number 
P  (S )  of  the  next  data  packet  to  be  transmitted  by  the  DCE  is  out¬ 
side  of  the  window,  the  DCE  shall  not  transmit  a  data  packet  to 

the  DTE.  The  DTE  should  follow  the  same  procedure. 

When  the  sequence  number  P(S)  of  the  data  packet  received  by  the 
DCE  is  the  next  in  sequence  and  is  within  the  window,  the  DCE 
will  accept  this  data  packet.  A  received  data  packet  containing 

a  P  (S )  that  is  out  of  sequence  (i.e.,  there  is  a  duplicate  or  a 

gap  in  the  P(S)  numbering),  outside  the  window,  or  not  equal  to  0 
for  the  first  data  packet  after  entering  the  FLOW  CONTROL  READY 
state  (dl)  is  considered  by  the  DCE  as  a  local  procedure  error. 
The  DCE  will  reset  the  virtual  call  or  permanent  virtual  circuit 
(see  section  4.4.3).  The  DTE  should  follow  the  same  procedure. 

Some  networks  do  not  invoke  the  error  procedure  on  receipt  of  a 
data  packet  containing  a  P(S)  that  is  out  of  sequence  but  is 
within  the  window.  These  networks  may  pass  on  such  packets  to 
the  remote  DTE  in  order  to  make  it  possible  for  the  local  DTE  to 
retransmit  packets  on  virtual  calls  or  permanent  virtual  circuits 
(within  the  national  network) . 


A  ni»mber  (modulo  8,  or  128  when  extended),  referred  to  as  a 
packet  receive  sequence  number  P(R),  conveys  across  the  DTE/DCE 
interface  information  from  the  receiver  for  the  transmission  of 
data  packets.  When  transmitted  across  the  DTE/DCE  interface,  a 
P(R)  becomes  the  lower  window  edge.  In  this  way,  additional  data 
packets  may  be  authorized  by  the  receiver  to  cross  the  DTE/DCE 
interface. 

The  packet  receive  sequence  number,  P(R),  is  conveyed  in  data, 
receive  ready  (RR)  and  receive  not  ready  (RNR)  packets. 


The  value  of  a  P(R)  received  by  the  DCE  must  be  within  the  range 
from  the  last  P(R)  received  by  the  DCE  up  to  and  including  the 
packet  send  sequence  number  of  the  next  data  packet  to  be 
transmitted  by  the  DCE.  Otherwise,  the  DCE  will  consider  the 
Receipt  of  this  P(R)  as  a  procedure  error  and  will  reset  the  vir¬ 
tual  call  or  permanent  virtual  circuit.  The  DTE  should  follow 
the  same  procedure. 


The  receive  sequence  number  P (B )  is  less  than  or 
sequence  number  of  the  next  expected  data  packet 
the  DTE  or  DCE  transmitting  P(R)  has  accepted  £t 
packets  numbered  up  to  and  including  P(R)-1. 


equal  to  the 
and  implies  that 
least  all  data 
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When  the  D  bit  is  set  to  0  in  a  data  packet  having  P(S)  «  p,  the 
significance  of  the  returned  P (R )  corresponding  to  that  data 
packet  fi.e.,  P(R)  p+11  is  a  local  updating  of  the  window 
across  the  packet  level  interface  so  that  the  achievable 
throughput  is  not  constrained  by  the  DTE-to-DTE  round  trip  delay 
across  the  network(s). 


When  the  D  bit  is  set  to  1  in  a  data  packet  having  P  (S )  •  p,  the 
significance  of  the  returned  P  (R )  corresponding  to  that  data 
packet  U.e  ,  P(R)  >  p+11  is  an  indication  that  a  P(R)  has  been 
received  fi  i  the  remote  DTE  for  all  data  bits  in  the  data  packet 
in  which  the  D  bit  had  originally  been  set  to  1. 


Note  1:  A  DTE,  on  receiving  a  data  packet  with  the  D  bit  set  to 
1,  should  transmit  the  corresponding  P(R)  as  soon  as 
possible  in  order  to  avoid  the  possibility  of  deadlocks 
(e.g.,  without  waiting  for  further  data  packets).  A 
data,  RR  or  RNR  packet  may  be  used  to  convey  the  P(R) 
(see  Note  to  section  4. 4. 1.6).  Likewise,  the  DCE  is 
required  to  send  P(R)  to  the  DTE  as  soon  as  possible 
from  when  the  P(R)  is  received  from  the  remote  DTE. 


Note  2:  In  the  case  where  a  P(R)  for  a  data  packet  with  the  D 

bit  set  to  1  is  outstanding,  local  updating  of  the  win¬ 
dow  will  be  deferred  for  subsequent  data  packets  with 
the  D  bit  set  to  0.  Some  networks  may  also  defer  updat¬ 
ing  the  window  for  previous  data  packets  (within  the 
window)  with  the  D  bit  set  to  0  until  the  corresponding 
P(R)  for  the  packet  with  the  outstanding  D  bit  set  to  1 
is  transmitted  to  the  DTE. 


Note  3:  P(R)  values  corresponding  to  the  data  contained  in  data 
packets  with  the  D  bit  set  to  1  need  not  be  the  same  at 
the  DTE/DCE  interfaces  at  each  end  of  a  virtual  call  or 
a  permanent  virtual  circuit. 


4. 4. 1.5  DTE  and  DCE  Receive  Ready  (RR)  Packets 


RR  packets  are  used  by  the  DTE  or  DCE  to  indicate  that  it  is 
ready  to  receive  the  W  data  packets  within  the  window  starting 
with  PfR),  where  P(R)  is  indicated  in  the  RR  packet. 


4.4. 1.6  DTE  and  DCE  Receive  Not  Read) 


Packets 


RNR  packets  are  used  by  the  DTE  or  DCE  to  indicate  a  temporary 
inability  to  accept  additional  data  packets  for  a  given  virtual 
call  or  permanent  virtual  circuit.  A  DTE  or  DCE  receiving  an  RNR 
packet  shall  stop  transmitting  data  packets  on  the  indicated  log¬ 
ical  channel,  but  the  window  is  updated  by  the  P(R)  value  of  the 
RNR  packet.  The  receive  not  ready  situation  indicated  by  the 
transmission  of  an  RNR  packet  is  cleared  by  the  transmission  in 


the  same  direction  of  an  RR  packet  or  by  a  reset  procedure  being 
initiated . 

The  transmission  of  an  RR  packet  after  an  RNR  packet  at  the 
packet  level  is  not  to  be  taken  as  a  demand  for  retransmission  of 
packets  which  have  already  been  transmitted. 

Notes  The  RNR  packet  may  be  used  to  convey  across  the  DTE/DCE 
~  interface  the  P(R)  value  corresponding  to  a  data  packet 
which  had  the  D  bit  set  to  1  in  the  case  that  additional 
data  packets  cannot  be  accepted. 

4.4.2  Throughput  Characteristics  and  Throughput  Classes 

The  attainable  throughput  on  virtual  calls  and  permanent  virtual 
circuits  carried  at  the  DTE/DCE  interface  may  vary  due  to  the 
statistical  sharing  of  transmission  and  switch  resources  and  is 
constrained  by: 

(il  the  access  line  characteristics,  local  window  size  and 
traffic  characteristics  of  other  logical  channels  at 
the  local  DTE/DCE  interface, 

(ii)  the  access  line  characteristics,  local  window  size  and 
traffic  characteristics  of  other  logical  channels  at 
the  remote  DTE/DCE  interface,  and 

(iii)  the  throughput  achievable  on  the  virtual  call  or  per¬ 
manent  virtual  circuit  through  the  network(s)  indepen¬ 
dent  of  interface  characteristics  including  number  of 
active  logical  channels.  This  throughput  may  be  depen¬ 
dent  on  network  service  characteristics  such  as  window 
rotation  mechanisms  and/or  optional  user  facilities 
requested  on  national/international  calls. 

The  attainable  throughput  will  also  be  affected  by: 

(i)  the  receiving  DTE  flow  controlling  the  DCE, 

(ii)  the  transmitting  DTE  not  sending  data  packets  which 
have  the  maximum  data  field  length, 

(iii)  the  local  DTE/DCE  window  and/or  packet  sizes,  and 

(iv)  the  use  of  the  D  bit. 

A  throughput  class  for  one  direction  of  transmission  is  an 
inherent  characteristic  of  the  virtual  call  or  permanent  virtual 
circuit  related  to  the  amount  of  resources  allocated  to  thfs  vir¬ 
tual  call  or  permanent  virtual  circuit.  This  character  1st i e  is 
meaningful  when  the  D  bit  is  set  to  0  in  data  packets.  It  is  a 
measure  of  the  throughput  that  is  not  normally  exceeded  on  the 
virtual  call  or  permanent  virtual  circuit.  However,  due  to  the 


52 


statistical  sharing  of  transmission  and  switching  resources,  it 
is  not  guaranteed  that  the  throughput  class  can  be  reached  ion* 
of  the  tine. 

Depending  on  the  network  and  the  applicable  conditions  at  the 
considered  moment,  the  effective  throughput  may  exceed  the 
throughput  class. 

Note :  The  definition  of  throughput  class  as  a  grade  of  service 

parameter  is  for  further  study.  The  grade  of  service 
might  be  specified  when  the  D  bit  is  set  to  0  or  over  a 
time  period  between  the  completion  and  initiation  of  suc¬ 
cessive  D  bit  procedures. 

The  throughput  class  may  only  be  reached  if  the  following  condi¬ 
tions  are  met: 

(a)  the  access  data  links  of  both  ends  of  a  virtual  call  or 
permanent  virtual  circuit  are  engineered  for  the 
throughput  class; 

(b)  the  receiving  DTE  is  not  flow  controlling  the  DCE  such 
that  the  throughput  class  is  not  reachable; 

(c)  the  transmitting  DTE  is  sending  data  packets  which  have 
the  maximum  data  field  length;  and 

(d)  all  data  packets  transmitted  on  the  virtual  call  or 
permanent  virtual  circuit  have  the  D  bit  set  to  0. 

The  throughput  class  is  expressed  in  bits  per  second.  At  a 
DTE/DCE  interface,  the  maximum  data  field  length  is  specified  for 
a  virtual  call  or  permanent  virtual  circuit,  and  thus  the 
throughput  class  can  be  interpreted  by  the  DTE  as  the  number  of 
full  data  packets/second  that  the  DTE  does  not  have  a  need  to 
exceed . 

In  the  absence  of  the  Default  Throughput  Class  Assignment  facil- 
tly  (see  section  7.1.3),  the  default  throughput  classes  for  both 
directions  of  transmission  correspond  to  the  user  class  of  ser¬ 
vice  of  the  DTE  (see  section  7.4. 2.6)  but  do  not  exceed  the  max¬ 
imum  throughput  class  supported  by  the  network.  Negotiation  of 
throughput  classes  on  a  per  call  basis  may  be  made  with  the 
Throughput  Class  Negotiation  facility  (see  section  7.2.3). 

Note;  The  summation  of  throughput  classes  of  all  virtual  calls, 
permanent  virtual  circuits  and  datagram  logical  channels 
supported  at  a  DTE/DCE  interface  may  be  greater  than  the 
data  transmission  rate  of  the  access  line. 
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4 . 4 . 3  Procedure  f or  Reset 

The  reset  procedure  is  used  to  r e- in i t i al i ze  the  virtual  call  or 
permanent  virtual  circuit  and  in  so  doing  removes  in  each  direc¬ 
tion  all  data  and  interrupt  packets  which  may  be  in  the  network 
(se-j  section  4.5).  When  a  virtual  call  or  permanent  virtual  cir¬ 
cuit  at  the  DTE/DCE  interface  has  just  been  reset,  the  window 
related  to  each  direction  of  data  transmission  has  a  lower  window 
edge  equal  to  0,  and  the  numbering  of  subsequent  data  packets  to 
cross  the  DTE/DCE  interface  for  each  direction  of  data  transmis¬ 
sion  shall  start  from  0. 

The  reset  procedure  can  only  apply  in  the  DATA  TRANSFER  state 
( p4 )  of  the  DTE/DCE  interface.  In  any  other  state  of  the  DTE/DCE 
interface,  the  reset  procedure  is  abandoned.  For  example,  when  a 
clearing  or  restarting  procedure  is  initiated,  RESET  REQUEST  and 
RESET  INDICATION  packets  can  be  left  unconfirmed. 

For  flow  control,  there  are  three  states  dl,  d2  and  d3  within  the 
DATA  TRANSFER  state  <p4).  They  are  FLOW  CONTROL  READY  (dl ) ,  DTE 
RESET  REQUEST  <d2),  and  DCE  RESET  INDICATION  (d3)  as  shown  in  the 
state  diagram  in  Annex  2,  Figure  A2.3/X.25.  When  entering  state 
p4,  the  logical  channel  is  placed  in  state  dl.  Annex  3,  Table 
A3. 4 /x. 25  specifies  actions  taken  by  the  DCE  on  the  receipt  of 
packets  from  the  DTE. 

4. 4. 3.1  Reset  Request  Packet 

The  DTE  shall  indicate  a  request  for  reset  by  transmitting  a 
RESET  REQUEST  packet  specifying  the  logical  channel.  This  places 
the  logical  channel  in  the  DTE  RESET  REQUEST  state  (d2). 

4. 4. 3. 2  Reset  Indication  Packet 

The  DCE  shall  indicate  a  reset  by  transmitting  to  the  DTE  a  RESET 
INDICATION  packet  specifying  the  logical  channel  and  the  reason 
for  the  resetting.  This  places  the  logical  channel  in  the  DCE 
RESET  INDICATION  state  (d3).  In  this  state,  the  DCE  will  ignore 
data,  interrupt,  RR  and  RNR  packets. 

4. 4. 3. 3  Reset  Collision 

Reset  collision  occurs  when  a  DTE  and  a  DCE  simultaneously 
transmit  a  RESET  REOUEST  packet  and  a  RESET  INDICATION  packet 
specifying  the  same  logical  channel.  Under  this  circumstance  the 
DCE  will  consider  that  the  reset  is  completed.  The  DCE  will  not 
expect  a  DTE  RESET  CONFIRMATION  packet  and  will  not  transfer  a 
DCE  RESET  CONFIRMATION  packet.  This  places  the  logical  channel 
in  the  FLOW  CONTROL  READY  state  (dl). 


4. 4. 3. 4  Reset  Confirmation  Packets 


When  the  logical  channel  is  in  the  DTE  RESET  REQUEST  state  (rt?), 
the  DCE  will  confirm  reset  by  transmitting  to  the  DTE  a  DCE  RESET 
CONFIRMATION  packet.  This  places  the  logical  channel  in  the  FLO*-* 
CONTROL  READY  State  (dl). 

The  DCE  RESET  CONFIRMATION  packet  can  only  be  interpreted  univer¬ 
sally  as  having  local  significance,  however  within  some 
Administration's  networks  reset  confirmation  may  have  end  to  end 
significance.  In  all  cases  the  time  spent  in  the  DTE  RESET 
REQUEST  state  (d2)  will  not  exceed  time-limit  T22  (see  Annex  4). 

When  the  logical  channel  is  in  the  DCE  RESET  INDICATION  state 
fd3),  the  DTE  will  confirm  reset  by  transmitting  to  the  DCE  a  DTE 
RESET  CONFIRMATION  packet.  This  places  the  logical  channel  in 
the  FLOW  CONTROL  READY  state  (dl).  The  action  taken  by  the  DCE 
when  the  DTE  does  not  confirm  the  reset  within  time-out  T12  is 
given  in  Annex  4. 

4. 5  Effects  of  Clear,  Reset  and  Restart  Procedures  on  the 
Transfer  of  Packets 


All  data  and  interrupt  packets  generated  by  a  DTE  (or  the  net¬ 
work)  before  initiation  by  the  DTE  or  the  DCE  of  a  clear,  reset 
or  restart  procedure  at  the  local  interface  will  either  be 
delivered  to  the  remote  DTE  before  the  DCE  transmits  the 
corresponding  indication  on  the  remote  interface,  or  be  discarded 
by  the  network. 

No  data  or  interrupt  packets  generated  by  a  DTE  (or  the  network) 
after  the  completion  of  a  reset  (or  for  permanent  virtual  cir¬ 
cuits  also  a  restart)  procedure  at  the  local  Interface  will  be 
delivered  to  the  remote  DTE  before  the  completion  of  the 
corresponding  reset  procedure  at  the  remote  interface. 

When  a  DTE  initiates  a  clear,  reset  or  restart  procedure  on  its 
local  interface,  all  data  and  interrupt  packets  which  were  gen¬ 
erated  by  the  remote  DTE  (or  the  network)  before  the  correspond¬ 
ing  indication  is  transmitted  to  the  remote  DTE  will  be  either 
delivered*  to  the  initiating  DTE  before  DCE  confirmation  of  the 
initial  clear,  reset  or  restart  request,  or  be  discarded  by  the 
network . 

Notes  The  maximum  number  of  packets  which  may  be  discarded  is  a 
function  of  network  end-to-end  delay  and  throughput 
characteristics  and,  in  general,  has  no  relation  to  the 
local  window  size.  Provision  of  more  precise  information 
is  for  further  study.  For  virtual  calls  and  permanent 
virtual  circuits  on  which  all  data  packets  are  transferred 
with  the  D  bit  set  to  1,  the  maximum  number  of  packets 
which  may  be  discarded  in  one  direction  of  transmission  is 
not  larger  than  the  window  size  of  the  direction  of 
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transmission. 

4. «  Effects  of  Physical  and  Link,  Level  Failures 

When  a  failure  on  the  physical  and/or  link  level  is  detected,  the 
DCE  will  transmit  to  the  remote  end: 

(1)  a  reset  with  the  cause  "Out  of  order"  for  each  permanent 
virtual  circuit  and 

(2)  a  clear  with  the  cause  "Out  of  order"  for  each  existing 
virtual  call. 

During  the  failure,  the  DCE  will  clear  any  incoming  virtual 
calls. 

When  the  failure  is  recovered  on  the  physical  and  link  levels, 
the  restart  procedure  will  be  actioned  (see  section  3.5)  and  a 
reset  with  the  cause  "Remote  DTE  operational"  will  be  transmitted 
to  the  remote  end  of  each  permanent  virtual  circuit. 


5.  PROCEDURES  FOR  DATAGRAM  SERVICE 

Annex  2  shows  the  state  diagrams  which  give  a  definition  of 
events  at  the  packet  level  DTE/DCE  Interface  for  each  logical 
channel.  Figures  A2. 1/X. 25  and  A2. 3/X.25  apply  to  datagram  logi¬ 
cal  channels. 

Annex  3  gives  details  of  the  action  taken  by  the  DCE  on  receipt 
of  packets  in  each  state  shown  in  Annex  2.  Details  of  actions 
which  should  be  taken  by  the  DTE  are  for  further  study. 

There  is  no  call  set-up  or  clearing  for  datagrams. 

A  DTE  DATAGRAM  packet  includes  the  destination  DTE  address;  the 
source  DTE  address  may  also  be  used. 

A  DCE  DATAGRAM  packet  includes  the  source  DTE  address;  the  desti¬ 
nation  DTE  address  may  also  be  used. 

Note:  A  DTE  address  may  be  a  DTE  network  address,  an  abbreviated 
address  or  any  other  DTE  identification  agreed  for  a  period 
of  time  between  the  DTE  and  the  DCE. 

5. 1  Procedures  for  Datagram  Transfer 

The  data  transfer  procedure  applies  independently  to  each 
datagram  logical  channel  existing  at  the  DTE/DCE  Interface. 

Normal  network  operation  dictates  that  user  data  in  datagram 
packets  are  all  passed  transparently,  unaltered  through  the  net¬ 
work  in  the  case  of  packet  DTE  to  packet  DTE  communications. 
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Order  of  bits  of  user  data  is  preserved  within  a  datagram. 

5.1.1  States  for  Data  Transfer 

Dataqram  logical  channels  are  continually  in  the  DATA  TRANSFER 
state  (p*)  except  during  the  restart  procedure.  Datagram, 
datagram  service  signal,  flow  control,  and  reset  packets  nay  he 
transmitted  and  received  by  a  DTE  in  the  DATA  TRANSFER  state  of  a 
datagram  logical  channel  at  the  PTE/PdE  interface.  In  this 
state,  the  flow  control  and  reset  procedures  described  in  section 
^.2  apply  to  data  transmission  on  that  dataqram  logical  channel 
to  and  from  the  DTE. 


5.1.2  User  Data  Field  Length 

The  maximum  User  Data  field  length  for  datagrams  is  12P  octets. 

The  data  field  of  datagram  packets  transmitted  by  a  DTE  or  DCE 
may  contain  any  number  of  bits  up  to  the  maximum. 

Note:  At  present,  some  networks  require  the  data  field  to  con¬ 
tain  an  integral  number  of  octets  (see  section  3,  Note  2). 

5.1.3  Dataqram  Identification 


Each  datagram  transmitted  at  the  DTE/D CE  interface  for  each 
direction  of  transmission  may  be  uniquely  numbered  with  a 
datagram  identification  number.  Assignment  of  the  values  to  the 
datagram  identification  is  a  DTE  responsibility  and  may  be 
assigned  according  to  any  algorithm.  The  network  will  not 
operate  on  the  datagram  identification  except  to  return  the 
information  in  the  appropriate  network  generated  datagram  service 
signal  packet. 


5.1.4  Datagram  Service  Signals 


The  DCE  will  be  capable  of  transferring  to  the  DTE  service  sig¬ 
nals  as  specified  in  Recommendation  X.95.  The  datagram  service 
signals  will  be  carried  in  datagram  service  signal  packers. 
Datagram  service  signals  are  of  two  types  -  specific  and  general. 


5. 1.4.1  Dataqram  Service  Signal  -  Specific 


This  is  a  service  signal  generated  by  the  network  relative  to  a 
specific  datagram  issued  by  the  DTE.  There  are  three  classes  for 
this  type  of  service  signal: 


(a)  Dataqram  rejected  -  datagram  discarded  by  network;  a 
correction,  based  on  the  received  cause,  is  required 
before  trying  again. 


(b)  Datagram  non-delivery  indication  -  datagram  discarded 
by  network;  try  again  later  based  on  the  received 
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cause,  next  time  may  be  successful. 

Note ;  This  class  of  service  signal  is  only  issued  by 
the  network  when  the  non-delivery  indication 
facility  (see  section  7.3.4)  has  been  requested. 

(c)  Datagram  del i very  conf i rmation  -  datagram  has  been 
accepted  by  the  destination  DTE. 

Note:  This  class  of  service  signal  is  only  issued  by 

the  network  when  the  delivery  confirmation 
facility  (see  section  7.3.5)  has  been  requested. 

Datagram  service  signal  -  specific  packets  will  include  the 
address  information,  if  valid,  and  the  datagram  identification 
associated  with  the  original  datagram  for  which  the  service  sig¬ 
nal  applies.  The  original  destination  address  is  provided  in  the 
datagram  service  signal  packet  as  the  source  address  while  the 
original  source  address  is  shown  as  the  destination  address,  when 
present . 

5. 1.4. 2  Datagram  Service  Signal  -  General 

This  is  a  service  signal  generated  by  the  network  relative  to 
datagram  operation  but  not  to  any  specific  datagram  issued  by  the 
DTE. 


5. 2  Procedures  for  Flow  Control 

This  subsection  only  appl ies  to  the  DATA  TRANSFER  state  (p*)  and 
specifies  the  procedures  covering  flow  control  of  datagram  and 
datagram  service  signal  packets  and  reset  on  each  datagram  logi¬ 
cal  channel. 

5.2.1  Flow  Control 

At  the  DTE/DCE  interface  of  a  datagram  logical  channel,  the 
transmission  of  datagram  and  datagram  service  sign*:!  oackets  is 
controlled  separately  for  each  direction  and  is  based  cn  authori¬ 
zations  from  the  receiver.  Datagram  and  datagram  service  signal 
packets  are  referred  to  below  as  flow  controlled  packets. 

5. 2. 1.1  Numbering  of  Packets 

Each  datagram  and  datagram  service  signal  packet  transmitted  at 
the  DTE/DCE  interface  for  each  direction  of  transmission  on  a 
giver,  datagram  logical  channel  is  sequentially  numbered. 

The  sequence  numbering  scheme  of  the  packets  is  performed  modulo 
P.  The  packet  sequence  numbers  cycle  through  the  entire  range  0 
to  7.  Some  Admin i strat ions  will  provide  the  Extended  Packet 
Sequence  Numbering  facility  (see  section  7.1.1)  which,  if 
selected,  provides  a  sequence  numbering  scheme  for  packets  being 
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performed  modulo  128.  In  this  case,  packet  sequence  numbers 
cycle  through  the  entire  range  0  to  127.  The  packet  sequence 
numbering  scheme,  modulo  8  or  128,  is  the  sane  for  both  direc¬ 
tions  of  transmission  and  is  common  for  all  logical  channels  at 
the  DTF/DCE  interface. 

For  datagram  service,  only  datagram  and  datagram  service  signal 
packets  contain  this  sequence  number  called  the  packet  send 
sequence  number  P(S). 

The  first  datagram  or  datagram  service  signal  packet  to  be 
transmitted  across  the  PTE/DCE  Interface  for  a  given  direction  of 
data  transmission,  when  the  datagram  logical  channel  has  just 
entered  the  FLOW  CONTROL  REAPY  state  fdi),  kas  a  packet  send 
sequence  nunber  equal  to  0. 

5. 2. 1.2  Window  Description 

At  the  PTE/DCE  interface  of  a  datagram  logical  channel,  and  for 
each  direction  of  data  transmission,  a  window  is  defined  as  the 
ordered  set  of  W  consecutive  packet  send  sequence  numbers  of  the 
flow  controlled  packets  authorized  to  cross  the  interface. 

The  lowest  sequence  number  in  the  window  is  referred  to  as  the 
lower  window  edge.  When  the  datagram  logical  channel  has  just 
entered  the  FLOW  CONTROL  READY  state  (dl),  the  window  related  to 
each  direction  of  data  transmission  has  a  lower  window  edge  equal 
to  n . 

The  packet  send  sequence  number  of  the  first  flow  controlled 
packet  not  authorized  to  cross  the  interface  is  the  value  of  the 
lower  window  edge  plus  W  (modulo  8,  or  128  when  extended). 

The  standard  window  size  W  is  2  for  each  direction  of  data 
transmission  at  a  DTE/DCE  interface.  In  addition,  other  window 
sizes  may  be  offered  by  Administrations  and  may  be  selected  for  a 
period  of  time  for  each  datagram  logical  channel  (see  section 
*’.1.2). 

5. 2. 1.3  Flow  Control  Principles 

When  the  sequence  number  of  the  next  flow  controlled  packet  to  be 
transmitted  by  the  DCE  is  within  the  window,  the  DCE  is  author¬ 
ized  to  transmit  this  flow  controlled  packet  to  the  DTE.  When 
the  sequence  number  P(S)  of  the  next  flow  controlled  packet  to  be 
transmitted  by  the  DCE  is  outside  of  the  window,  the  DCE  shall 
not  transmit  a  flow  controlled  packet  to  the  DTE.  The  DTE  should 
follow  the  same  procedure. 

When  the  sequence  number  P(S)  of  the  flow  controlled  packet 
received  by  the  DCE  is  the  next  in  sequence  and  is  within  the 
window,  the  DCE  will  accept  this  flow  controlled  packet.  A 
received  flow  controlled  packet  containing  a  PfS)  that  is  out  of 
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sequence  (i.e.,  there  is  a  duplicate  or  a  gap  in  the  P(S)  number¬ 
ing),  outside  the  window,  or  not  equal  to  zero  for  the  first  flow 
controlled  packet  after  entering  the  FLOW  CONTROL  READY  state 
(dl)  is  considered  by  the  DCE  as  a  local  procedure  error.  The 
DCE  will  reset  the  datagram  logical  channel  (see  section  5.2.3). 
The  DTE  should  follow  the  same  procedure. 

A  number  (modulo  R,  or  128  when  extended),  referred  to  as  a 
packet  receive  sequence  number  P(R),  conveys  across  the  DTE/DCE 
interface  information  from  the  receiver  for  the  transmission  of 
flow  controlled  packets.  When  transmitted  across  the  DTE/DCE 
interface,  a  P(R)  becomes  the  lower  window  edge.  In  this  way, 
additional  flow  controlled  packets  may  be  authorized  by  the 
receiver  to  cross  the  DTE/DCE  interface. 

The  packet  receive  sequence  number,  P(R),  is  conveyed  in 
datagram,  datagram  service  signal,  receive  ready  (RR)  and  receive 
not  ready  (RNR)  packets. 

The  value  of  a  P(R)  received  by  the  DCE  must  be  within  the  range 
from  the  last  P(R)  received  by  the  DCE  up  to  and  including  the 
packet  send  sequence  number  of  the  next  flow  controlled  packet  to 
be  transmitted  by  the  DCE.  Otherwise,  the  DCE  will  consider  the 
receipt  of  this  P(R)  as  a  procedure  error  and  will  reset  the  log¬ 
ical  channel.  The  DTE  should  follow  the  same  procedure. 

The  receive  sequence  number  P(R)  is  less  than  or  equal  to  the 
sequence  number  of  the  next  expected  flow  controlled  packet  and 
implies  that  the  DTE  or  DCE  transmitting  P(R)  has  accepted  at 
least  all  flow  controlled  packets  numbered  up  to  and  including 
P  (R )  -1 . 

The  only  significance  of  a  P(R)  value  is  a  local  updating  of  the 
window  across  the  packet  level  interface. 

5. 2. 1.4  Datagram  Queue 

The  network  maintains  a  datagram  queue  for  each  datagram  logical 
channel  at  destination  DCE.  The  maximum  length  of  the  aueue  for 
each  datagram  logical  channel  is  agreed  for  a  period  ot 
between  the  DTE  and  the  Administration  (see  section  7.3.2). 

Datagram  service  signal  packets  have  priority  over  other  datagram 
packets  and  are  Inserted  at  the  beginning  of  the  queue.  This  may 
lead  to  the  DCE  discarding  the  last  datagram  packet  of  the  queue 
if  the  maximum  queue  length  is  exceeded.  When  the  queue  is  full, 
additional  arriving  datagrams  are  discarded. 

By  agreement  for  a  period  of  time  between  the  DTE  and  the 
Administration  (see  section  7.3.3),  a  special  datagram  logical 
channel  may  be  assigned  for  the  transmission  of  datagram  service 
signals.  In  this  case,  the  maximum  length  of  the  queues  for 
datagrams  and  datagram  service  signals  are  independently  agreed 
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between  the  DTE  and  the  Administration. 

If  the  DTE  flow  controls  the  receipt  of  dataqran  service  signal 
packets,  the  DCE  cannot  guarantee  to  store  an  indefinite  number 
of  service  signals.  Therefore,  there  is  a  possibility  of  loss  of 
service  signal  packets  at  the  DCE.  A  possible  coupling  nechanisn 
to  allow  the  DCE  to  regulate  the  number  of  datagrams  generated  by 
the  DTE  in  relation  to  the  capacity  of  the  DCE  to  store  the 
datagram  service  signals  will  be  studied  to  determine  whether 
such  losses  at  the  DCE  should  be  prevented. 

5.2. 1.5  DTE  and  DCE  Receive  Ready  (RR)  Packets 

RR  packets  are  used  by  the  DTE  or  DCE  to  Indicate  that  it  is 
ready  to  receive  the  W  flow  controlled  packets  within  the  window 
starting  with  P(R),  where  P(R)  is  indicated  in  the  RR  packet. 

5. 2. 1.6  DTE  and  DCE  Receive  Not  Ready  (RNR)  Packets 

RNR  packets  are  used  by  the  DTE  or  DCE  to  indicate  a  temporary 
inability  to  accept  additional  flow  controlled  packets  for  a 
given  datagram  logical  channel.  A  DTE  or  DCE  receiving  an  RNR 
packet  shall  stop  transmitting  flow  controlled  packets  on  the 
indicated  datagram  logical  channel,  but  the  window  is  updated  by 
the  P (R )  value  of  the  RNR  packet.  The  receive  not  ready  situa¬ 
tion  indicated  by  the  transmission  of  RNR  packet  is  cleared  by 
the  transmission  in  the  same  direction  of  an  RR  packet  or  by  a 
reset  procedure  being  initiated. 

The  transmission  of  an  RR  after  an  RNR  at  the  packet  level  is  not 
to  be  taken  as  a  demand  for  retransmission  of  packets  which  have 
already  been  transmitted. 

5.2.2  Throughput  Characteristics 

Throughput  is  the  effective  data  transfer  rate  measured  in  bits 
per  second. 

For  each  datagram  logical  channel,  a  throughput  class  for  each 
direction  of  data  transmission  at  the  DTE/DCE  interface  Is  agreed 
for  a  period  of  time  between  the  DTE  and  the  Administration  (see 
section  7.1.3). 

Relating  to  datagram  operation,  the  following  has  been  identified 
for  further  study: 

(a)  The  attainment  of  throughput  on  a  given  datagram  logi¬ 
cal  channel. 

(b)  The  necessity  for  discriminating  between  throughput  on 
datagram  logical  channels  compared  with  logical  chan¬ 
nels  used  for  virtual  calls  and  permanent  virtual  cir¬ 
cuits. 
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5.2.3  Procedure  for  Reset 

The  reset  procedure  is  used  to  re-initial  ize  the  dataqram  logical 
channel.  When  a  datagram  logical  channel  at  the  DTE/DCE  inter¬ 
face  has  just  been  reset,  the  window  related  to  each  direction  of 
data  transmission  has  a  lower  window  edge  equal  to  0,  and  the 
numbering  of  subsequent  flow  controlled  packets  to  cross  the 
DTE/DCE  Interface  for  each  direction  of  data  transmission  shall 
start  from  0. 

For  datagram  logical  channels,  the  reset  procedure  causes 
datagrams  and  datagram  service  signals  to  be  purged  from  the  DCE 
queue  associated  with  that  datagram  logical  channel.  A  datagram 
service  signal  with  the  cause  "Remote  procedure  error"  will  be 
issued  to  the  remote  end  for  each  datagram  requesting  the  non¬ 
delivery  indication  facility. 

The  reset  procedure  can  only  apply  in  the  DATA  TRANSFER  state 
(p4)  cf  the  DTE/DCE  interface.  In  any  other  state  of  the  DTE/DCE 
interface,  the  reset  procedure  is  abandoned.  For  example,  when  a 
restarting  procedure  is  initiated,  RESET  REQUEST  and  RESET  INDI¬ 
CATION  packets  can  be  left  unconfirmed. 

For  flow  control,  there  are  three  states  dl,  d2,  and  d3  within 
the  DATA  TRANSFER  state  (p4).  They  are  FLOW  CONTROL  READY  (dl ) , 
DTE  RESET  REQUEST  (d2),  and  DCE  RESET  INDICATION  (d3)  as  shown  in 
the  state  diagram  in  Annex  2,  Figure  A2.3/X.25.  When  entering 
state  p4,  the  datagram  logical  channel  is  placed  in  state  dl. 
Annex  3,  Table  A3.4/X.25  specifies  actions  taken  by  the  DCE  on 
the  receipt  of  packets  from  the  DTE. 

5.2. 3.1  Reset  Request  Packet 

The  DTE  shall  indicate  a  request  for  reset  by  transmitting  a 
RESET  REQUEST  packet  specifying  the  datagram  logical  channel. 

This  places  the  datagram  logical  channel  in  the  DTE  RESET  REQUEST 
state  (d2). 

5. 2. 3. 2  Reset  Indication  Packet 


The  DCE  shall  indicate  a  reset  by  transmitting  to  the  DTE  a  RESET 
INDICATION  packet  specifying  the  datagram  logical  channel  and  the 
reason  for  the  resetting.  This  places  the  datagram  logical  chan¬ 
nel  in  the  DCE  RESET  INDICATION  state  (d3).  In  this  state,  the 
DCE  will  Ignore  datagram,  RR  and  RNR  packets. 

5. 2. 3. 3  Reset  Col llslon 

Reset  collision  occurs  when  a  DTE  and  a  DCE  simultaneously 
transmit  a  RESET  REQUEST  packet  and  a  RESET  INDICATION  packet 
specifying  the  same  datagram  logical  channel.  Under  this  cir¬ 
cumstance,  the  DCE  will  consider  the  reset  completed.  The  DCE 
will  not  expect  a  DTE  RESET  CONFIRMATION  packet  and  will  not 


transfer  a  DCE  RESET  CONFIRMATION  packet.  This  places  the 
datagram  logical  channel  in  the  FLOW  CONTROL  READY  state  (dl). 

5. 2. 3. 4  Reset  Confirmation  Packets 


When  the  datagram  logical  channel  is  in  the  DTE  RESET  REQUEST 
state  (d2),  the  DCE  will  confirm  reset  by  transmitting  to  the  DTE 
a  DCE  RESET  CONFIRMATION  packet.  This  places  the  datagram  logi¬ 
cal  channel  in  the  FLOW  CONTROL  READY  state  (dl). 


The  DCE  RESET  CONFIRMATION  packet  has  local  significance.  The 
time  spent  in  the  DTE  RESET  REQUEST  state  (d2)  will  not  exceed 
time-limit  T22  (see  Annex  4). 

When  the  datagram  logical  channel  is  in  the  DCE  RESET  INDICATION 
state,  the  DTE  will  confirm  reset  by  transmitting  to  the  DCE  a 
DTE  RESET  CONFIRMATION  packet.  This  places  the  datagram  logical 
channel  in  the  FLOW  CONTROL  READY  state  (dl).  The  action  taken 
by  the  DCE  when  the  DTE  does  not  confirm  the  reset  within  time¬ 
out  T12  is  given  in  Annex  4. 

5. 3  Effects  of  Reset  and  Restart  Procedures  on  the  Transfer  of 
Packets 


For  datagram  logical  channels,  the  reset  and  restart  procedures 
cause  datagrams  and  datagram  service  signals  to  be  purged  from 
the  DCE  queue.  A  datagram  service  signal  with  the  cause  "Remote 
procedure  error"  will  be  issued  to  the  remote  end  for  each 
datagram  requesting  the  non-delivery  indication  facility. 

5. 4  Effects  of  Physical  and  Link  Level  Failures 

When  a  failure  on  physical  and/or  link  level  is  detected,  the  DCE 
will  purge  datagrams  and  datagram  service  signals  from  the  DCE 
queue  associated  with  each  datagram  logical  channel  and,  for  each 
datagram  requesting  the  non-delivery  indication  facility, 
transmit  to  the  remote  end  a  datagram  service  signal  with  the 
cause  "Out  of  order". 

During  the  failure,  the  DCE  will  discard  any  incoming  datagrams 
and  datagram  service  signals.  A  datagram  service  signal  with  the 
cause  "Out  of  order"  will  be  sent  to  the  remote  end  for  each 
datagram  requesting  the  non-delivery  indication  facility. 

When  the  failure  is  recovered  on  the  physical  and  link  levels, 
the  restart  procedure  will  be  actioned  (see  section  3.5).  Upon 
completion  of  this  procedure,  Incoming  datagrams  and  datagram 
service  signals  will  be  handled  in  the  normal  manner. 
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fi.  PACKET  FORMATS 

6. 1  General 

The  possible  extension  of  packet  formats  by  the  addition  of  new 
fields  is  for  further  study. 

Note;  Any  such  field: 

(a)  would  only  be  provided  as  an  addition  following  all  pre¬ 
viously  defined  fields,  and  not  as  an  insertion  between 
any  of  the  previously  defined  fields. 

(b)  would  be  transmitted  to  a  DTE  only  when  either  the  DCE 
has  been  Informed  that  the  DTE  is  able  to  interpret  this 
field  and  act  upon  it,  or  when  the  DTE  can  ignore  the 
field  without  adversely  affecting  the  operation  of  the 
DCE. 

(c)  would  not  contain  any  information  pertaining  to  a  user 
facility  to  which  the  DTE  has  not  subscribed. 

Bits  of  an  octet  are  numbered  8  to  1  where  bit  1  is  the  low  order 
bit  and  is  transmitted  first.  Octets  of  a  packet  are  consecu¬ 
tively  numbered  starting  from  1  and  are  transmitted  in  this 
order . 

8.1.1  General  Format  Identifier 

The  General  Format  Identifier  field  is  a  four  bit  binary  coded 
field  which  is  provided  to  indicate  the  general  format  of  the 
rest  of  the  header.  The  General  Format  Identifier  field  is 
located  in  bit  positions  8,  7,  6  and  5  of  octet  1,  and  bit  5  is 
the  low  order  bit  (see  Table  6.1/X.25). 
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TABLE  8.1/X.25 
GENERAL  FORMAT  IDENTIFIER 


|  Octet  1 

GENERAL  FORMAT  IDENTIFIER  J  bits 

i  8  7  8  5 

Call  set-up 
packets 

Sequence  numbering  scheme  ;  0  x  0  1  ‘ 
modulo  8  j 

Sequence  numbering  scheme 
modulo  128 

o  x  l  n  | 

i 

Clearing,  datagram,  flow 
control,  interrupt, 
reset,  restart  and 
diagnostic  packets 

Sequence  numbering  scheme 
modulo  8 

0  0  0  1 

1 

Sequence  numbering  scheme 
modulo  128 

o  o  i  o  ! 

1 

Data  packets 

Sequence  numbering  scheme 
modulo  8 

X  X  0  1 

Sequence  numbering  scheme 
modulo  128 

x  x  l  n 

Datagram  service  signal 
packets 

Sequence  numbering  scheme 
modulo  8 

10  0  1 

Sequence  numbering  scheme 
modulo  128 

10  10 

General  Format  Identifier  extension 

••11 

•Undefined 


Note?  A  bit  which  is  indicated  as  "X"  may  be  set  to  either  "0"  or 
"1"  as  discussed  in  subsequent  sections. 


Bit  8  of  the  General  Format  Identifier  is  used  for  the  Qualifier 
bit  in  data  packets.  It  is  set  to  1  in  datagram  service  signal 
packets  and  is  set  to  0  in  all  other  packets. 

Bit  7  of  the  General  Format  Identifier  is  used  for  the  delivery 
confirmation  procedure  in  data  and  call  set-up  packets  and  is  set 
to  n  In  all  other  packets. 

Bits  8  and  5  are  encoded  for  four  possible  indications.  Two  of 
the  codes  are  used  to  distinguish  packets  using  modulo  8  sequence 
numbering  from  packets  using  modulo  128  sequence  numbering.  The 
third  code  is  used  to  Indicate  an  extension  to  an  expanded  format 


for  a  family  of  General  Format  Identifier  codes  which  are  a  sub¬ 
ject  of  further  study.  The  fourth  code  is  unassigned. 

Note  1:  In  the  absence  of  the  Extended  Packet  Sequence  Numberinq 
facility  (see  section  7.1.1),  the  sequence  numbering 
scheme  is  performed  modulo  6. 

Note  2:  It  is  envisaged  that  other  General  Format  Identifier 
codes  could  identify  alternative  packet  formats. 

6.1.2  Logical  Channel  Group  Number 

The  Logical  Channel  Group  Number  appears  in  every  packet  except 
restart  packets  and  diagnostic  packets  in  bit  positions  4,  3,  2 
and  1  of  octet  1.  For  each  logical  channel,  this  number  has 
local  significance  at  the  DTE/DCE  interface. 

This  field  is  binary  coded  and  bit  1  is  the  low  order  bit  of  the 
Logical  Channel  Group  Number.  In  restart  and  diagnostic  packets, 
this  field  is  coded  all  zeros. 

6.1.3  Logical  Channel  Number 

The  Logical  Channel  Number  appears  in  every  packet  except  restart 
packets  and  diagnostic  packets  in  all  bit  position,  of  octet  2. 
For  **ach  logical  channel,  this  number  has  local  significance  at 
the  DTE/DCE  interface. 

This  field  is  binary  coded  and  bit  1  is  the  low  order  bit  of  the 
Logical  Channel  Number.  In  restart  and  diagnostic  packets,  this 
field  is  coded  all  zeros. 

6.1.4  Packet  Type  Identifier 

Each  packet  shall  be  identified  in  octet  3  of  the  packet  accord¬ 
ing  to  Table  6.2/X.25. 


TABLE  6.2/X.25 
PACKET  TYPE  IDENTIFIER 


PACKET 

TYPE 

8 

7 

OCTET 

BITS 

6  5  4 

3 

3 

2 

! 

1 

FROM  DCE  TO  DTE 

FROM  DTE  TO  DCE 

CALL  SET-UP 

AND  CLEARING 

} 

1 

INCOMING  CALL 

CALL  REQUEST 

0 

0 

0 

0 

1 

0 

1 

l  : 

CALL  CONNECTED 

CALL  ACCEPTED 

0 

0 

0 

0 

1 

1 

1 

1 

CLEAR  INDICATION 

CLEAR  REOUEST 

0 

0 

0 

1 

0 

0 

1 

1 

DCE  CLEAR  CONFIRMATION 

DTE  CLEAR  CONFIRMATION 

0 

0 

0 

1 

0 

1 

1 

1 

DATA  AND 

INTERRUPT 

DCE  DATA 

DTE  DATA 

X 

X 

X 

X 

X 

X 

X 

0 

DCE  INTERRUPT 

DTE  INTERRUPT 

0 

0 

1 

0 

0 

0 

1 

1 

DCE  INTERRUPT 

DTE  INTERRUPT 

CONFIRMATION 

CONFIRMATION 

0 

0 

1 

0 

0 

1 

1 

1 

DATAGRAM* 

DCE  DATAGRAM 

DTE  DATAGRAM 

X 

X 

X 

X 

X 

X 

X 

0 

DATAGRAM  SERVICE  SIGNAL 

X 

X 

X 

X 

X 

X 

X 

0 

FLOW  CONTROL  AND  RESET 

_J>C£  RR  (MODULO  8} 

DTE  RR  (MODULE  8) 

X 

X 

X 

0 

0 

0 

0 

1 

DCE  RR  (MODULO  128)* 

DTE  RR  (MODULO  128)* 

0 

0 

0 

0 

0 

0 

0 

1 

DCE  RNR  (MODULO  8) 

DTE  RNR  (MODULO  8) 

X 

X 

X 

0 

0 

1 

0 

1 

DCE  RNR  (MODULO  128)* 

DTE  RNR  (MODULO  128)* 

0 

0 

0 

0 

0 

1 

0 

1 

DTE  REJ  (MODULO  8)* 

X 

X 

X 

0 

1 

0 

0 

1 

DTE  REJ  (MODULO  128)* 

0 

0 

0 

0 

1 

0 

0 

1 

RESET  INDICATION 

RESET  REQUEST 

0 

0 

0 

1 

1 

0 

1 

1 

DCE  RESET  CONFIRMATION 

DTE  RESET  CONFIRMATION 

0 

0 

1 

1 

1 

1 

1 

RESTART 

RESTART  INDICATION 

RESTART  REQUEST 

1 

1 

1 

1 

1 

0 

1 

1 

DCE  RESTART  CONFIRMATION  DTE  RESTART  CONFIRMATION 

1 

1 

1 

1 

1 

1 

1 

1 

DIAGNOSTIC 

DIAGNOSTIC* 

1 

1 

1 

1 

0 

0 

0 

1 

*  Mot  necessarily  available  on  every  network. 


Mote;  A  bit  which  is  indicated  as  “X"  may  be  set  to  either  a0a  or 
ala  as  discussed  in  subsequent  sections. 
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6. 2  Call  Set-Up  and  Clearing  Packets 

6.2.1  Call  Request  and  Incoming  Call  Packets 

Figure  6.1/X.2S  illustrates  the  format  of  CALL  REQUEST  and  INCOM¬ 
ING  CALL  packets. 

General  Format  Identifier 

Bit  7  of  octet  1  should  be  set  to  0  unless  the  mechanism  defined 
in  section  4.3.3  is  used. 

Address  Lengths  Field 

Octet  4  consists  of  field  length  Indicators  for  the  called  and 
calling  DTE  addresses.  Bits  4,  3,  2  and  1  indicate  the  length  of 
the  called  DTE  address  In  semi-octets.  Bits  6,  7,  6  and  5  indi¬ 
cate  the  length  of  the  calling  DTE  address  in  semi-octets.  Each 
address  length  indicator  is  binary  coded  and  bit  1  or  5  is  the 
low  order  bit  of  the  indicator. 

Address  Field 


Octet  S  and  the  following  octets  consist  of  the  called  DTE 
address  when  present,  then  the  calling  DTE  address  when  present. 

Each  digit  of  an  address  is  coded  in  a  semi-octet  in  binary  coded 
decimal  with  bit  5  or  1  being  the  low-order  bit  of  the  digit. 

Starting  from  the  high  order  digit,  the  address  is  coded  in  octet 
S  and  consecutive  octets  with  two  digits  per  octet.  In  each 
octet,  the  higher  order  digit  is  coded  in  bits  8,  7,  6  and  5. 

The  Address  field  shall  be  rounded  up  to  an  integral  number  of 
octets  by  inserting  zeros  in  bits  4,  3,  2  and  1  of  the  last  octet 
of  the  field  when  necessary. 

Note:  This  field  may  be  used  for  optional  addressing  facilities 
such  as  abbreviated  addressing.  The  optional  addressing 
facilities  employed  as  well  as  the  coding  of  those  facili¬ 
ties  is  for  further  study. 

Facility  Length  Field 

Bits  6,  5,  4,  3,  2  and  1  of  the  octet  following  the  Address  field 
indicate  the  length  of  the  Facility  field  in  octets.  The  facil¬ 
ity  length  indicator  is  binary  coded  and  bit  1  is  the  low  order 
bit  of  the  indicator. 

Bits  8  and  7  of  this  octet  are  unasslgned  and  set  to  0. 


Oct  et 


Bits 

5  *• 


General  Fermat 

,  Identifier, 

(  See  Note  1  ) 


Logical  Channel 
Group  Kuz.be  r 


3  0 


Logical 

Channel  Number 

Packet  Type  Identifier 
0  0  10 


Calling  DTE  address 
length 


Called  DTE  address 
length 


DTE  Address  (Bee  Note  2) 


Facilities 


Call  User  Data 
(See  Notes  3  and  4) 


Note  1:  Coded  0X01  (modulo  8)  or  0X10  (modulo  128). 

Note  2:  The  figure  is  dravn  assuming  a  single  address  is 
present  consisting  of  an  odd  number  of  digits. 

Note  3;  Bits  8  and  7  of  the  first  octet  of  the  Call 

User  Data  field  may  have  particular  significance 
(see  section  6.2.1). 

Note  4:  Maximum  length  of  the  Call  User  Data  field  ia 
16  octets. 


Figure  6.1/X.25  -  Call  request  and  incoming  call  packet  fomat 
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Facility  Field 

The  Facility  field  is  present  only  when  the  DTE  is  using  an 
optional  user  facility  requiring  some  indication  in  the  CALL 
REQUEST  and  INCOMING  CALL  packets. 

The  coding  of  the  Facility  field  is  defined  in  section  7. 

The  Facility  field  contains  an  integral  number  of  octets.  The 
actual  maximum  length  of  this  field  depends  on  the  facilities 
which  are  offered  by  the  network.  However,  this  maximum  does  not 
exceed  63  octets. 

Call  User  Data  Field 

Following  the  Facility  field,  the  Call  User  Data  field  may  be 
present  and  has  a  maximum  length  of  16  octets. 

Note:  At  present,  some  networks  require  the  Call  User  Data 

field  to  contain  an  Integral  number  of  octets  (see  sec¬ 
tion  3,  Note  2). 

If  the  Call  User  Data  field  is  present,  the  use  and  format  of 
this  field  is  determined  by  bits  8  and  7  of  the  first  octet  of 
this  field  (see  Note)  . 

If  bits  8  and  7  of  the  first  octet  of  the  Call  User  Data  field 
are  00,  a  portion  of  the  Call  User  Data  field  is  used  for  proto¬ 
col  identif ication  in  accordance  with  other  CCITT  Recommendations 
such  as  Recommendation  X.29. 

If  bits  8  and  7  of  the  first  octet  of  the  Call  User  Data  field 
are  01,  a  portion  of  the  Call  User  Data  field  may  be  used  for 
protocol  Identification  in  accordance  with  specifications  of 
Administrations. 

If  bits  8  and  7  of  the  first  octet  of  the  Call  User  Data  field 
are  10,  a  portion  of  the  Call  User  Data  field  may  be  used  for 
protocol  identification  in  accordance  with  specifications  of 
international  user  bodies. 

If  bits  8  and  7  of  the  first  octet  of  the  Call  User  Data  field 
are  11,  no  constraints  are  placed  on  the  use  by  the  DTE  of  the 
remainder  of  the  Call  User  Data  field. 

Users  are  cautioned  that  if  bits  8  and  7  of  the  first  octet  of 
the  Call  User  Data  field  have  any  value  other  than  11,  a  protocol 
may  be  identified  that  is  Implemented  within  public  data  net¬ 
works  . 

Note:  When  a  virtual  call  is  being  established  between  two  packet 
mode  DTEs ,  the  network  does  not  act  on  any  part  of  the  Call 
User  Data  field,  unless  required  to  do  otherwise  by  an 
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appropriate  request  for  an  optional  user  facility  on  a  per 
call  basis.  Such  a  facility  is  for  further  study. 

6.2.2  Call  Accepted  and  Call  Connected  Packets 

Figure  6.2/X.25  illustrates  the  format  of  CALL  ACCEPTED  and  CALL 
CONNECTED  packets. 

General  Format  Identifier 


Bit  7  of  octet  1  should  be  set  to  0  unless  the  mechanism  defined 
in  section  4.3.3  is  used. 

Address  Lengths  Field 

Octet  4  consists  of  field  length  indicators  for  the  called  and 
calling  DTE  addresses.  Bits  4,  3,  2  and  1  indicate  the  length  of 
the  called  DTE  address  in  semi-octets.  Bits  8,  7,  6  and  5  indi¬ 
cate  the  length  of  the  calling  DTE  address  in  semi-octets.  Each 
address  length  indicator  is  binary  coded  and  bit  1  or  5  is  the 
low  order  bit  of  the  indicator. 

The  use  of  the  Address  Lengths  field  in  CALL  ACCEPTED  packets  is 
only  mandatory  when  the  Address  field  or  the  Facility  Length 
field  is  present. 

Address  Field 


Octet  5  and  the  following  octets  consist  of  the  called  DTE 
address  when  present,  then  the  calling  DTE  address  when  present. 

Each  digit  of  an  address  is  coded  in  a  semi-octet  in  binary  coded 
decimal  with  bit  5  or  1  being  the  low-order  bit  of  the  digit. 

Starting  from  the  high  order  digit,  the  address  is  coded  in 
octet  5  and  consecutive  octets  with  two  digits  per  octet.  In 
each  octet,  the  higher  order  digit  is  coded  in  bits  8,  7,  6  and 
5. 

The  Address  field  shall  be  rounded  up  to  an  integral  number  of 
octets  by  Inserting  zeros  in  bits  4,  3,  2  and  1  of  the  last  octet 
of  the  field  when  necessary. 

Note:  This  field  may  be  used  for  optional  addressing  facilities 
such  as  abbreviated  addressing.  The  optional  addressing 
facilities  employed  as  well  as  the  coding  of  those  facili¬ 
ties  is  for  further  study. 
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Bits 


Octet 


1 

2 

3 

It 


8  7  6  5 

It  3  2  1 

General  Format 

Logical  Channel 

Identifier 

Group  Number 

(  See  Note  l) 

Logical 

Channel  Number 

Packet  Type  Identifier 

0  0  0  0 

1111 

Calling  DTE  address 

Called  DTE  address 

length* 

length* 

|  DTE  Address  (See  Note  2)* 

I  I - 


l _ 

0  0  0  0 

0  0 

Facility  length* 

1 

1 

Facilities* 

1 

1 

i 

I 

i 

» 

j 


Note  1:  Coded  0X01  (modulo  8)  or  0Xl0  (modulo  128). 

Note  2:  The  figure  is  drawn  assuming  a  single  address 

is  present  consisting  of  an  odd  number  of  digits. 

These  fields  are  not  mandatory  in  CALL  ACCEPTED  packets 
(see  section  6.2.2). 

Figure  6.2/X.25  -  Call  accepted  and  call  connected  packet  format 


Bits  6,  5,  4,  3,  2  and  1  of  the  octet  following  the  Address  field 
indicate  the  length  of  the  Facility  field  in  octets.  The  facil¬ 
ity  length  indicator  is  binary  coded  and  bit  1  is  the  low  order 
bit  of  the  indicator. 

Bits  8  and  7  of  this  octet  are  unassigned  and  set  to  0. 

The  use  of  the  Facility  Length  field  in  CALL  ACCEPTED  packets  is 
only  mandatory  when  the  Facility  field  is  present. 

Facility  Field 

The  Facility  field  is  present  only  when  the  DTE  is  using  an 
optional  user  facility  requiring  some  indication  in  the  CALL 
ACCEPTED  and  CALL  CONNECTED  packets. 

The  coding  of  the  Facility  field  is  defined  in  section  7. 

The  Facility  field  contains  an  integral  number  of  octets.  The 
actual  maximum  length  of  this  field  depends  on  the  facilities 
which  are  offered  by  the  network.  However*  this  maximum  does  not 
exceed  63  octets. 


6,2.3  Clear  Request  and  Clear  Indication  Packets 

Figure  6.3/X.25  illustrates  the  format  of  CLEAR  REQUEST  and  CLEAR 
INDICATION  packets. 

Clearing  Cause  Field 

Octet  4  is  the  Clearing  Cause  field  and  contains  the  reason  for 
the  clearing  of  the  call. 

The  bits  of  the  Clearing  Cause  field  in  CLEAR  REQUEST  packets 
should  be  set  to  0  by  the  DTE.  It  is  for  further  study  whether 
other  values  of  these  bits  are  ignored  or  processed  by  the  DCE. 

The  coding  of  the  Clearing  Cause  field  in  CLEAR  INDICATION  pack¬ 
ets  is  given  in  Table  6.3/X.25. 


-ft  73 


Bits 

8765  1*321 


1 

General  Format 
Identifier 

See  Note 

Logical  Channel 

Grour  Number 

c 

Logical 

Channel  Number 

3 

0 

Packet  Type  Identifier 

0  0  1  0  0  1  1 

1* 

Clearing  Cause 

5 

• 

Diagnostic  Code 

#  Note :  Coded  0001  (modulo  8)  or  0010  (modulo  128) 

This  field  is  not  mandatory  in  CLEAR  REQUEST  packets. 


Figure  6.3/X.25  -  Clear  request  and  clear  indication  packet  format 


Bits 


8765  1*321 


1 

General  Format 
Identifier 

See  Note 

Logical  Channel 

Group  Number 

Logical 

2 

Channel  Number 

Packet  Type  Identifier 

3 

0  0  0  1 

0  111  | 

Note:  Coded  0001  (modulo  8)  or  0010  (modulo  128) 

Figure  6.WX.25-  DTE  and  DCE  clear  confirmation  packet  format 


TABLE  6.3/X.25 

CODING  OF  CLEARING  CAUSE  FIELD  IN  CLEAR  INDICATION  PACKET 


8 

7 

fi 

5 

4 

3 

2 

Tj 

j  DTE  originated 

0 

0 

□ 

0 

□ 

0 

0 

0  1 

1  Number  busy 

0 

0 

0 

0 

0 

0 

1  ! 

Out  of  order 

0 

0 

0 

0 

1 

0 

0 

1 

1  Remote  procedure  error 

0 

0 

□ 

1 

□ 

□ 

0 

i  ; 

Reverse  charging  acceptance 

i 

not  subscribed* 

0 

n 

0 

1 

1 

0 

0 

i  • 

(  Incompatible  destination 

0 

□ 

1 

0 

0 

0 

0 

i  i 

'  Fast  select  acceptance 

i 

not  subscribed* 

0 

0 

1 

0 

1 

0 

□ 

i 

. -  _  -  -  -  _  -  _ 

— 

- 

— 

— 

— 

Invalid  facility  request 

0 

0 

0 

0 

0 

□ 

1 

i  • 

Access  barred 

0 

0 

FJ 

0 

1 

0 

1 

i 

Local  procedure  error 

0 

□ 

0 

1 

0 

0 

1 

i  • 

Network  congestion 

0 

0 

0 

0 

0 

1 

0 

1 1 

■  Not  obtainable 

0 

0 

□ 

□ 

1 

1 

0 

i 

j  RPOA  out  of  order* 

0 

0 

0 

1 

0 

1 

0 

U 

*  May  be  received  only  if  the  corresponding  optional  user  facil¬ 
ity  is  used. 


Diagnostic  Code 

Octet  5  is  the  Diagnostic  Code  and  contains  additional  informa¬ 
tion  on  the  reason  for  the  clearing  of  the  call. 

In  a  CLEAR  REQUEST  packet*  the  Diagnostic  Code  is  not  mandatory. 

In  a  CLEAR  INDICATION  packet*  if  the  Clearing  Cause  field  indi¬ 
cates  "DTE  originated**  the  Diagnostic  Code  is  passed  unchanged 
from  the  clearing  DTE.  If  the  clearing  DTE  has  not  provided  a 
Diagnostic  Cede  in  its  CLEAR  REQUEST  packet*  then  the  bits  of  the 
Diagnostic  Code  in  the  resulting  CLEAR  INDICATION  packet  will  all 
be  sero. 


When  a  CLEAR  INDICATION  packet  results  from  a  RESTART  REQUEST 
packet*  the  value  of  the  Diagnostic  Code  will  be  that  specified 
in  the  RESTART  REQUEST  packet*  or  all  seros  in  the  case  where  no 
Diagnostic  Code  has  been  specified  in  RESTART  REQUEST. 


When  the  Clearing  Cause  field  does  not  indicate  "DTE  originat 
ed**  the  Diagnostic  Code  in  a  CLEAR  INDICATION  packet  is  network 
generated.  Annex  5  lists  the  codings  for  network  generated 
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diagnostics.  The  bits  of  the  Diagnostic  Code  are  all  set  to  0 
when  no  specific  additional  information  for  the  clearing  Is  sup¬ 
plied  . 

Mote:  The  contents  of  the  Diagnostic  Code  field  do  not  alter  the 
meaning  of  the  Cause  field.  A  DTE  is  not  required  to 
undertake  any  action  on  the  contents  of  the  Diagnostic 
Code  field.  Unspecified  code  combinations  in  the  Diagnos¬ 
tic  Code  field  shall  not  cause  the  DTE  to  not  accept  the 
Cause  field. 

6.2.4  DTE  and  DCS  Clear  Confirmation  Packets 

Figure  6.4/X.25  illustrates  the  format  of  the  DTE  and  DCE  CLEAR 
CONFIRMATION  packets. 

6*3  Data  and  Interrupt  Packets 

6.3.1  DTE  and  DCE  Data  Packets 

Figure  6.5/X.25  illustrates  the  format  of  the  DTE  and  DCE  DATA 
packets. 

Qualifier  Bit 

Bit  8  of  octet  1  is  the  Qualifier  bit. 

Delivery  Confirmation  Bit 

Bit  7  of  octet  1  is  the  Delivery  Confirmation  bit. 

Packet  Receive  Sequence  Number 

Bits  8,  7  and  6  of  octet  3  or  bits  8  through  2  of  octet  4,  when 
extended,  are  used  for  indicating  the  Packet  Receive  Sequence 
Number  P(R).  P(R)  is  binary  coded  and  bit  6,  or  bit  2  when 
extended,  is  the  low  order  bit. 

More  Data  Bit 

Bit  5  in  octet  3,  or  bit  1  in  octet  4  when  extended,  is  used  for 
the  More  Data  marks  0  for  no  more  data  and  1  for  more  data. 

Packet  Send  Sequence  Number 

Bits  4,  3  and  2  of  octet  3,  or  bits  8  through  2  of  octet  3  when 
extended,  are  used  for  indicating  the  Packet  Send  Sequence  Number 
P(S).  P (S )  is  binary  coded  and  bit  2  is  the  low  order  bit. 
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User  Data  Field 

Bits  following  octet  3,  or  octet  4  when  extended,  contain  user 
data. 

Note:  At  present,  some  networks  require  the  User  Data  field  to 

contain  an  Integral  number  of  octets  (see  section  3,  Note 
2) . 

6.3.2  DTE  and  DCE  Interrupt  Packets 

Figure  6.6/X.25  illustrates  the  format  of  the  DTE  and  DCE  INTER¬ 
RUPT  packets. 

Interrupt  User  Data  Field 

Octet  4  contains  user  data. 

6.3.3  DTE*and  DCE  Interrupt  Confirmation  Packets 

Figure  6.7/X.25  illustrates  the  format  of  the  DTE  and  DCE  INTER¬ 
RUPT  CONFIRMATION  packets. 

6. 4  Datagram  and  Datagram  Service  Signal  Packets 
6.4.1  DTE  and  DCE  Datagram  Packets 

Figure  6.8/X.25  illustrates  the  format  of  DTE  and  DCE  DATAGRAM 
packets . 

Packet  Receive  Sequence  Number 

Bits  8,  7  and  6  of  octet  3,  or  bits  8  through  2  of  octet  4  when 
extended,  are  used  for  indicating  the  Packet  Receive  Sequence 
Number  P(R).  P(R)  is  binary  coded  and  bit  6,  or  bit  2  when 
extended,  Is  the  low  order  bit. 

Packet  Send  Sequence  Number 

Bits  4,  3  and  2  of  octet  3,  or  bits  8  through  2  of  octet  3  when 
extended,  are  used  for  indicating  the  Packet  Send  Sequence 
Number  P(S).  P(S)  is  binary  coded  and  bit  2  is  the  low  order 
bit. 

Address  Lengths  Field 

The  octet  following  the  sequence  numbers  consists  of  field  length 
indicators  for  the  destination  and  source  DTE  addresses.  Bits  4, 
3,  2  and  1  indicate  the  length  olf  the  destination  DTE  address  in 
semi-octets.  Bits  8,  7,  6  and  5  indicate  the  length  of  the 
source  DTE  address  in  semi-octets*.  Each  address  length  Indicator 
is  binary  coded  and  bit  1  or  5  it*  the  low  order  bit  of  the  indi¬ 
cator. 
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Octet 


Octet 


Bits 


6  7  6  5 

L  3  2  1 

General  Format 

Logical  Channel 

Identifier 

1 

See  Note 

Group  Number 

Logical 

/■> 

c 

Channel 

Nur.be  r  | 

Packet  Type  Identifier  1 

0  0  10 

0  Cl  1  | 

u 

Interrupt  User  Data 

Note:  Coded  0001  (modulo  8)  or  0010  (modulo  128) 
Figure  6.6/X.25  -  DTE  and  DCE  interrupt  packet  format 


Bits 

67651*321 


General  Format 

Logical  Channel 

Identifier 

See  note 

Group  Number 

Logical  I 

Channel 

Number  j 

Packet  Type  Identifier  i 

0 

0  10 

0  111 

m  coded  0001  (modulo  8)  or  0010  (modulo  128) 

/X. 25  -  DTE  and  DCE  interrupt  confirmation  packet  format 


•It* 
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Address  Field 


The  octets  following  the  Address  Length  field  consist  of  the  des¬ 
tination  DTE  address  when  present,  then  the  source  DTE  address 
when  present. 

Each  digit  of  an  address  is  coded  in  a  semi-octet  in  binary  coded 
decimal  with  bit  5  or  1  being  the  low-order  bit  of  the  digit. 

Starting  from  the  high  order  digit,  the  address  is  coded  in  con¬ 
secutive  octets  with  two  digits  per  octet.  In  each  octet,  the 
higher  order  digit  is  coded  in  bits  8,  7,  6  and  5. 

The  Address  field  shall  be  rounded  up  to  an  integral  number  of 
octets  by  Inserting  zeros  in  bits  4,  3,  2  and  1  of  the  last  octet 
of  the  field  when  necessary. 

Note:  This  field  may  be  used  for  optional  addressing  facilities 
such  as  abbreviated  addressing.  The  optional  addressing 
facilities  employed  as  well  as  the  coding  of  those  facili¬ 
ties  is  for  further  study. 

Facility  Length  Field 

Bits  6,  5,  4,  3,  2  and  1  of  the  octet  following  the  Address  field 
indicate  the  length  of  the  Facility  field  in  octets.  The  facil¬ 
ity  length  Indicator  is  binary  coded  and  bit  1  is  the  low  order 
bit  of  the  Indicator. 

Bits  8  and  7  of  this  octet  are  unassigned  and  set  to  0. 

Facility  Field 

The  Facility  field  is  present  only  when  the  DTE  is  using  an 
optional  user  facility  requiring  some  indication  in  the  datagram 
packet . 

The  coding  of  this  Facility  field  is  defined  in  section  7. 

The  Facility  field  contains  an  Integral  number  of  octets.  The 
actual  maximum  length  of  this  field  depends  on  the  facilities 
which  are  offered  by  the  network.  However  this  maximum  does  not 
exceed  63  octets. 

User  Data  Field 


Following  the  Facility  field,  the  User  Data  field  may  be  present 
and  has  a  maximum  length  of  128  octets.  The  first  two  octets  of 
the  User  Data  field  are  called  the  datagram  Identification. 

Mote:  At  present,  some  networks  require  the  User  Data  field  to 

contain  an  integral  number  of  octets  (see  section  3,  Note 

2). 


6.4.2  Datagram  Service  Signal  Packets 

Figure  6.9/X.25  illustrates  the  format  of  DATAGRAM  SERVICE  SIGNAL 
packets. 

Packet  Receive  Sequence  Number 

Bits  8,  7  and  6  of  octet  3,  or  bits  8  through  2  of  octet  4  when 
extended,  are  used  for  indicating  the  Packet  Receive  Sequence 
Number  P(R).  P(R)  is  binary  coded  and  bit  6,  or  bit  2  when 
extended,  is  the  low  order  bit. 

Packet  Send  Sequence  Number 

Bit  4,  3  and  2  of  octet  3,  or  bits  8  through  2  of  octet  3  when 
extended,  are  used  for  indicating  the  Packet  Send  Sequence 
Number  P(S).  P(S)  is  binary  coded  and  bit  2  is  the  low  order 
bit. 

Address  Lengths  Field 

The  octet  following  the  sequence  numbers  consists  of  field  length 
indicators  for  the  destination  and  source  DTE  addresses.  Bits  4, 
3,  2  and  1  indicate  the  length  of  the  destination  DTE  address  in 
semi-octets.  Bits  8,  7,  6  and  S  indicate  the  length  of  the 
source  DTE  address  in  semi-octets.  Each  address  length  indicator 
is  binary  coded  and  bit  1  or  5  is  the  low  order  bit  of  the  indi¬ 
cator. 

The  source  DTE  address  length  indicator  is  coded  all  zeros  for 
datagram  service  signal  -  general  packets. 

Address  Field 


The  octets  following  the  Address  Length  field  consist  of  the  des¬ 
tination  DTE  address  when  present,  then  the  source  DTE  address 
when  present  (see  section  5. 1.4.1), 

Each  digit  of  an  address  is  coded  in  a  semi-octet  in  binary  coded 
decimal  with  bit  5  or  1  being  the  low-order  bit  of  the  digit. 

Starting  from  the  high  order  digit,  the  address  is  coded  in  con¬ 
secutive  octets  with  two  digits  per  octet.  In  each  octet,  the 
higher  order  digit  is  coded  in  bits  8,  7,  6  and  5. 


The  Address  field  shall  be  rounded  up  to  an  integral  number  of 
octets  by  inserting  zeros  in  bits  4,  3,  2  and  1  of  the  last  octet 
of  the  field  when  necessary. 


Figure  6.9/X.25  -  Datagram  service  signal  packet  format 


Datagram  Identification  Field 


The  Datagram  Identification  field  of  datagram  service  signal  - 
specific  packets  contains  the  first  two  octets  of  the  User  Data 
field  from  the  original  datagram  to  which  the  datagram  service 
signal  packet  applies.  If  the  User  Data  field  of  the  original 
datagram  is  less  than  two  octets,  the  Datagram  Identification 
field  in  the  datagram  service  signal  packet  will  be  padded  out  to 
two  octets  by  inserting  the  appropriate  number  of  0  bits. 

The  Datagram  Identification  field  of  datagram  service  signal  - 
general  packets  is  coded  with  all  zeros. 

Cause  Field 


The  octet  immediately  following  the  Datagram  Identification  field 
is  the  Cause  field  and  contains  the  reason  for  the  datagram  ser¬ 
vice  signal. 

The  coding  of  the  Cause  field  is  given  in  Table  S.4/X.25. 


TABLE  S.4/X.2S 

CODING  OF  CAUSE  FIELD  IN  DATAGRAM  SERVICE  SIGNAL  PACKET 


P 

7 

6 

5 

4 

3 

2 

M 

Datagram  Service  Signal  -  Specific 

1 

Datagram  Rejected 

1 

1 

Local  procedure  error 

0 

0 

0 

1 

0 

0 

1 

1 

;i 

Invalid  facility  request 

0 

0 

Li 

0 

Kil 

0 

1 

}  i 

Access  barred 

0 

0 

0 

0 

1 

0 

1 

1  i 

Not  obtainable 

0 

0 

0 

0 

1 

1 

u 

1 

Incompatible  destination 

0 

0 

1 

LJ 

0 

0 

□ 

1 

Reverse  charging  acceptance 

0 

0 

u 

1 

1 

0 

0 

1 

not  subscribed 

Datagram  Non-Delivery  Indication 

(Note  1) 

Network  congestion 

0 

0 

□ 

□ 

0 

1 

□ 

1 

Out  of  order 

0 

0 

0 

0 

1 

Id 

0 

1 

Number  busy  (destination  queue 

full) 

0 

u 

0 

0 

0 

0 

0 

1 

Remote  procedure  error 

0 

0 

0 

1 

0 

0 

0 

1 

Datagram  Delivery  Confirmation  (Note  2) 

Delivery  confirmation 

0 

0 

1 

1 

D 

u 

D 

1 

Datagram  Service  Signal  -  General 

Local  DCE  queue  overflow  (Note 

3) 

B 

1 

1 

1 

1 

1 

1 

1 

Network  congestion 

D 

1 

u 

0 

0 

1 

1 

1 

Network  operational 

LI 

1 

El 

0 

1 

1 

1 

1 

Nott  1:  Issued  only  when  the  Non-delivery  Indication  facility 
~  (see  section  7.3.4)  has  been  requested. 

Note  2:  Issued  only  when  the  Delivery  Confirmation  facility  (see 
section  7.3.S)  has  been  requested. 

Note  3;  For  further  study. 


Diagnostic  Code 

The  octet  Immediately  following  the  Cause  field  contains  addi¬ 
tional  Information  on  the  reason  for  the  datagram  service  signal. 


The  coding  of  the  Diagnostic  Code  field  is  given  in  Annex  5. 
Assigned  Diagnostic  Codes  applicable  to  datagram  service  signal 
packets  include  decimal  33,  38,  39,  40,  65,  66,  67  and  68.  The 
bits  of  the  Diagnostic  Code  in  a  datagram  service  signal  packet 
are  all  set  to  zero  when  no  specific  additional  information  for 
the  service  signal  is  supplied. 

Note:  The  contents  of  the  Di agnostic  Code  field  do  not  alter  the 
meaning  of  the  Cause  field.  A  DTE  is  not  required  to 
undertake  any  action  on  the  contents  of  the  Diagnostic 
Code  field.  Unspecified  code  combinations  in  the  Diagnos¬ 
tic  Code  field  shall  not  cause  the  DTE  to  not  accept  the 
Cause  field. 

Network  Information  Field 


Following  the  Diagnostic  Code  field,  the  Network  Information 
field  may  be  present  and  has  a  maximum  length  of  16  octets. 

If  the  Diagnostic  Code  field  designates  Facility  Code  Not  Allowed 
or  Facility  Parameter  Not  Allowed,  then  the  Network  Information 
field  will  contain  the  octets  associated  with  the  facility  code 
and  its  associated  parameter  field.  If  the  Diagnostic  Code  field 
designates  Invalid  Address,  then  the  Network  Information  Field 
will  contain  the  octets  associated  with  the  two  Address  Length 
fields  and  the  octets  associated  with  the  Address  field. 

The  information  content  of  this  field  for  other  Diagnostic  Codes 
is  for  further  study. 

6.5  Flow  Control  and  Reset  Packets 


6.5.1  DTE  and  DCE  Receive  Ready  (RR)  Packets 

Figure  6.10/X.25  illustrates  the  format  of  the  DTE  and  DCE  RR 
packets . 

Packet  Receive  Sequence  Number 

Bits  8,  7  and  6  of  octet  3,  or  bits  8  through  2  of  octet  4  when 
extended,  are  used  for  indicating  the  Packet  Receive  Sequence 
Number  P(R).  P(R)  is  binary  coded  and  bit  6,  or  bit  2  when 
extended,  is  the  low  order  bit. 

6.5.2  DTE  and  DCE  Receive  Not  Ready  (RNR)  Packets 

Figure  6.11/X.25  illustrates  the  format  of  the  DTE  and  DCE  RNR 
packets. 
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Packet  Receive  Sequence  Number 


Bits  8,  7  and  6  of  octet  3,  or  bits  8  through  2  of  octet  4  when 
extended,  are  used  for  indicating  the  Packet  Receive  Sequence 
Number  P(R).  P(R)  is  binary  coded  and  bit  6,  or  bit  2  when 
extended,  is  the  low  order  bit. 


6.5.3  Reset  Request  and  Reset  Indication  Packets 


Figure  6.12/X.25  illustrates  the  format  of  the  RESET  REQUEST  and 
RESET  INDICATION  packets. 


Resetting  Cause  Field 


Octet  4  is  the  Resetting  Cause  field  and  contains  the  reason  for 
the  reset. 


The  bits  of  the  Resetting  Cause  field  in  a  RESET  REQUEST  packet 
should  be  set  to  0  by  the  DTE.  It  is  for  further  study  whether 
other  values  of  these  bits  are  ignored  or  processed  by  the  DCE. 

The  coding  of  the  Resetting  Cause  field  in  a  RESET  INDICATION 
packet  is  given  in  Table  6.5/X.25. 

TABLE  6.5/X.25 


CODING  OF  RESETTING  CAUSE  FIELD  IN  RESET  INDICATION  PACKET 


87654321 

DTE  originated** 

00000000 

Out  of  order* 

00000001 

Remote  procedure  error** 

00000011 

Local  procedure  error 

00000101 

Network  congestion 

00000111 

Remote  DTE  operational* 

00001001 

Network  operational*** 

0  0  0  0  1  1  1  1 

Incompatible  destination** 

00010001 

Applicable  to  permanent  virtual  circuits  only. 


**  Applicable  to  virtual  calls  and  permanent  virtual  circuits  only. 

***  Applicable  to  permanent  virtual  circuits  and  datagram  logical 
channels  only. 
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Bits 


Octet  1 

2 

3 

1» 

5 

Note:  Coded  0001  (modulo  8)  or  0010  (modulo  128) 

•  This  field  is  not  mandatory  in  RESET  RE5’JE3T  packets. 

Figure  6.12/X.25  -  Reset  request  and  reset  indication  packet  format 


General  Format 
Identifier 
See  Note 


Logical  Channel 
Group  Number 


Logical 
Channel  Number 


0 

0 

Packet  Type  Identifier 

0  110 

1 

1 

Resetting  Cause 

• 

Diagnostic  Code 

Octet  1 


Bits 

5 


General  Format 
Identifier 
See  Note 


Logical  Channel 
Group  Number 


Logical 

Channel  Number 


Packet  Type  Identifier 

oiii 


Note:  Coded  0001  (modulo  6)  or  0010  (modulo  128) 

Figure  6.13/X.25  -  DTE  and  DCE  reset  confirmation  packet  fr.raa 


Dlaanostlc  Code 


Octet  5  is  the  Diagnostic  Code  and  contains  additional  informa¬ 
tion  on  the  reason  for  the  reset. 

In  a  RESET  REQUEST  packet  the  Diagnostic  code  is  not  mandatory. 

In  a  RESET  INDICATION  packet,  if  the  Resetting  Cause  field  indi¬ 
cates  "DTE  originated,"  the  Diagnostic  Code  has  been  passed 
unchanged  from  the  resetting  DTE.  If  the  DTE  requesting  a  reset 
has  not  provided  a  Diagnostic  Code  in  its  RESET  REQUEST  packet, 
then  the  bits  of  the  Diagnostic  Code  in  the  resulting  RESET  INDI¬ 
CATION  packet  will  all  be  zeros. 

If  a  RESET  INDICATION  packet  results  from  a  RESTART  REQUEST 
packet,  the  value  of  the  Diagnostic  Code  will  be  that  specified 
in  the  RESTART  REQUEST,  or  all  zeros  in  the  case  where  no  Diag¬ 
nostic  Code  has  been  specified  in  RESTART  REQUEST. 

If  the  Resetting  Cause  field  does  not  indicate  "DTE  originated”, 
the  Diagnostic  Code  in  a  RESET  INDICATION  packet  is  network  gen¬ 
erated.  Annex  5  lists  the  codings  for  network  generated  diagnos¬ 
tics.  The  bits  of  the  Diagnostic  Code  are  all  set  to  0  when  no 
specific  additional  Information  for  the  reset  is  supplied. 

Note:  The  contents  of  the  Diagnostic  Code  field  do  not  alter  the 
meaning  of  the  Cause  field.  A  DTE  is  not  required  to 
undertake  any  action  on  the  contents  of  the  Diagnostic 
Code  field.  Unspecified  code  combinations  in  the  Diagnos¬ 
tic  Code  field  shall  not  cause  the  DTE  to  not  accept  the 
Cause  field. 

6.5.4  DTE  and  DCS  Reset  Confirmation  Packets 

Figure  6.13/X.25  illustrates  the  format  of  the  DTE  and  DCE  RESET 
CONFIRMATION  packets. 

6.6  Restart  Packets 


6.6.1  Restart  Request  and  Restart  Indication  Packets 

Figure  6.14/X.25  illustrates  the  format  of  the  RESTART  REQUEST 
and  RESTART  INDICATION  packets. 

Restarting  Cause  Field 

Octet  4  is  the  Restarting  Cause  field  and  contains  the  reason  for 
the  restart. 

The  bits  of  the  Restarting  Cause  field  in  RESTART  REQUEST  packets 
should  be  set  to  0  by  the  DTE.  It  is  for  further  study  whether 
other  values  of  these  bits  are  ignored  or  processed  by  the  DCE. 
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Bits 

t  7  6  S  fc  3  2  1 


Oct  et  1 

2 

3 

1» 

5 

Note:  Coded  0001  (modulo  8}  or  0010  (modulo  128) 

*  This  field  is  not  mandatory  in  RESTART  REQUEST  packets 
Figure  6.14/X.25  -  Restart  request  and  restart  indication  packet  format 


General  Format 

Identifier 

See  Note 

0  0 

G 

G 

0 

0  0  0 

0  0 
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0  0 
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Note:  Coded  0001  (modulo  8)  or  0010  (modulo  126) 


Figure  6.15/X.25  -  DTE  ana  DCE  restart  confirmation  packet  format 


The  coding  of  the  Restarting  Cause  field  in  the  RESTART  INDICA 
TION  packets  is  given  in  Table  6.6/X.25. 

TABLE  6.6/X.25 

CODING  OF  RESTARTING  CAUSE  FIELD  IN  RESTART 
INDICATION  PACKETS 


8  7  6  5  4  3  2  1 

Local  procedure  error 

Network  congestion 

Network  operational 

00000001 

0  0  0  0  0  0  1  1 
00000111 

Diagnostic  Code 

Octet  5  is  the  Diagnostic  Code  and  contains  additional  informa¬ 
tion  on  the  reason  for  the  restart. 

In  a  RESTART  REQUEST  packet,  the  Diagnostic  Code  is  not  manda¬ 
tory.  The  Diagnostic  Code,  if  specified,  is  passed  to  the 
corresponding  DTEs  as  the  Diagnostic  Code  of  a  RESET  INDICATION 
packet  for  permanent  virtual  circuits  or  a  CLEAR  INDICATION 
packet  for  virtual  calls. 

The  coding  of  Diagnostic  Code  field  in  a  RESTART  INDICATION 
packet  is  given  in  Annex  5.  The  bits  of  the  Diagnostic  Code  are 
all  set  to  zero  when  no  specific  additional  information  for  the 
restart  is  supplied. 

Note:  The  contents  of  the  Diagnostic  Code  field  do  not  alter  the 
meaning  of  the  Cause  field.  A  DTE  is  not  required  to 
undertake  any  action  on  the  contents  of  the  Diagnostic 
Code  field.  Unspecified  code  combinations  in  the  Diagnos¬ 
tic  Code  field  shall  not  cause  the  DTE  to  not  accept  the 
Cause  field. 

6.6.2  DTE  and  DCE  Restart  Confirmation  Packets 

Figure  6.15/X.25  illustrates  the  format  of  the  DTE  and  DCE  RES¬ 
TART  CONFIRMATION  packets. 

6.7  Diagnostic  Packet 

Figure  6.16/X.25  illustrates  the  format  of  the  DIAGNOSTIC  packet. 


1111  000  1 
Packet  Type  Identifier 


Diagnostic  Code 


i  i 

|  t 

|  Diagnostic  Explanation  j 

i  (See  Note  2)  i 

j _ I 


Note  1:  Coded  0001  (modulo  8)  or  0010  (modulo  128) 

Note  2:  The  figure  is  drawn  assuming  the  Diagnostic 
Explanation  field  is  an  integral  number  of 
octets  in  length. 


Figure  6.16/X.25  -  Diagnostic  packet  format 


Diagnostic  Code  Field 

Octet  4  is  the  diagnostic  code  and  contains  information  on  the 
error  condition  which  resulted  in  the  transm ission  of  the  DIAG¬ 
NOSTIC  packet.  The  coding  of  the  Diagnostic  Code  field  is  given 
in  Annex  5. 

Diagnostic  Explanation  Field 

When  the  DIAGNOSTIC  packet  is  Issued  as  a  result  of  the  reception 
of  an  erroneous  packet  from  the  DTE  (see  Table  A3.1/X.25),  this 
field  contains  the  first  three  octets  of  header  information  from 
the  erroneous  DTE  packet.  If  the  packet  contains  less  than  3 
octets,  this  field  contains  whatever  bits  were  received. 

When  the  DIAGNOSTIC  packet  is  issued  as  a  result  of  a  DCE  timeout 
(see  Table  A4.1/X.25),  the  Diagnostic  Explanation  field  contains 
2  octets  coded  as  follows: 

-  Bits  8,  7,  fi  and  5  of  the  first  octet  contains  the  General 
Format  Identifier  for  the  interface. 

-  Bits  4  to  1  of  the  first  octet  and  bits  8  to  1  of  the  second 
octet  are  all  0  for  expiration  of  time-out  T10  and  give  the 
number  of  the  logical  channel  on  which  the  time-out  occurred 
for  expiration  of  time-out  T12  or  T13. 

6. 8  Packets  Required  for  Optional  User  Facilities 

8.8.1  DTE  Reject  (REJ)  Packet  For  The  Packet  Retransmission 
Facility 

Figure  S.17/X.25  illustrates  the  format  of  the  DTE  REJ  packets, 
used  in  conjunction  with  the  Packet  Retransmission  facility 
described  in  section  7.1.4. 

Packet  Receive  Sequence  Number 

Bits  8,  7  and  6  of  octet  3,  or  bits  8  through  2  of  octet  4  when 
extended,  are  used  for  Indicating  the  Packet  Receive  Sequence 
Number  P(R).  P(R)  is  binary  coded  and  bit  8,  or  bit  2  when 
extended,  is  the  low  order  bit. 

6.8.2  Call  Set-up  and  Clearing  Packets  For  The  Fast  Select 
Facility  and  East  Select  Acceptance  Facility 

6. 8. 2.1  Call  Request  and  Incoming  Call  Packets 

Figure  6.18/X.25  illustrates  the  format  of  CALL  REOUEST  and 
INCOMING  CALL  packets  used  in  conjunction  with  the  Fast  Select 
facility  and  Fast  Select  Acceptance  facility  described  in  sec¬ 
tions  7.2.4  and  7.2.5, 


Octet.  1 


General  Foraat 
Identifier 


Logical  Channel 
Group  Number 


2 - Q _ U 


C 

Logical 

Channel  Number 

3 

P(R) 

Packet  Type  Identifier 

0  1  0  0 

1 

(Modulo  8) 


Bits 

6  7  6  5  J*  3 

2  1 

General  Format 

Logical  Channel  1 

Identifier 

Grouo  Number 

Octet  1 

0  0  10 

Logical 

2 

Channel  Number 

Packet  Type  Identifier  j 

3 

0  0  0  0 

1  0 

J 

l 

P(R) 

B 

(When  extended  to  modulo  128) 


Figure  6.17/X.25  -  DTE  REJ  packet  format 


Octet 


-A96  : 


Bits 

6  7  6  5  1*321 


General  Format 

,  Identifier 
(See  Note  1) 

Logical  Channel 

Group  Number 

Logical 

Channel  Number 

Packet  Type  Identifier 

0000  1011 

Calling  DTE  address 
length 

Called  DTE  address 
length 

|  DTE  Address 

(see  Note  2)  1 

1 

1 

1 - - - - 

0  0  0  0 

0  0 

Facility  length 

I 

i 

1 

1 

Facilities  J 

1 

1 

r 

~  — - 1 

l 

Call  User  Data  1 

i 

(See  Notes  3  and  U)  j 

L _ 

— - 1 

Note  1:  Coded  0X01  (modulo  8)  or  0X10  (modulo  128). 

Note  2:  The  figure  is  drawn  assuming  a  single  address  is 
present  consisting  of  an  odd  number  of  digits. 

Note  3:  Bits  8  and  7  of  the  first  octet  of  the  Call 

User  Data  field  may  have  particular  significance 
(see  section  6.2.1). 

Note  1*:  Maximum  length  of  the  Call  User  Data  field  is 
128  octets. 


Figure  6.18/X.25  -  Call  request  and  incoming  call  packet  format 
for  the  Fast  Select  facility 
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Description  of  section  6.2.1  is  applied  to  this  section  except 
the  length  of  the  Call  User  Data  field  has  a  maximum  length  of 
128  octets. 

Note:  At  present,  some  networks  require  the  Call  User  Data 

field  to  contain  an  Integral  number  of  octets  (see  sec¬ 
tion  3,  Note  2). 

6.8. 2. 2  Call  Accepted  and  Call  Connected  Packets 

Figure  6.19/X.25  illustrates  the  format  of  CALL  ACCEPTED  and  CALL 
CONNECTED  packets  used  in  conjunction  with  the  Fast  Select  facil¬ 
ity  and  Fast  Select  Acceptance  facility  described  in  sections 
7.2.4  and  7.2.5. 

Description  of  section  6.2.2  is  applied  to  this  section  and,  in 
addition,  the  Called  User  Data  field  may  be  present  and  has  a 
maximum  length  of  128  octets.  The  Address  Lengths  field  and 
Facility  Length  field  are  mandatory. 

Note:  At  present,  some  networks  require  the  Cal.ed  User  Data 

field  to  contain  an  integral  number  of  octets  (see  sec¬ 
tion  3,  Note  2). 

If  the  Called  User  Data  field  is  present,  the  use  and  format  of 
this  field  is  determined  by  bits  8  and  7  of  the  first  octet  of 
this  field  (see  Note). 

If  bits  8  and  7  of  the  first  octet  of  the  Called  User  Data  field 
are  00,  a  portion  of  the  Called  User  Data  field  is  used  for  pro¬ 
tocol  identification  in  accordance  with  other  CCITT  Recommenda¬ 
tions  . 

If  bits  8  and  7  of  the  first  octet  of  the  Called  User  Data  field 
are  01,  a  portion  of  the  Called  User  Data  field  may  be  used  for 
protocol  identification  in  accordance  with  specifications  of 
Administrations. 

If  bits  8  and  7  of  the  first  octet  of  the  Called  Us j r  Data  field 
are  10,  a  portion  of  the  Called  User  Data  field  may  be  used  for 
protocol  identification  in  accordance  with  specifications  of 
International  user  bodies. 

If  bits  8  and  7  of  the  first  octet  of  the  Called  User  Data  field 
are  11,  no  constraints  are  placed  on  the  use  by  the  DTE  of  the 
remainder  of  the  Called  User  Data  field. 

Users  are  cautioned  that  if  bits  8  and  7  of  the  first  octet  of 
the  Called  User  Data  field  have  any  value  other  than  11,  a  proto¬ 
col  may  be  identified  that  is  implemented  within  public  data  net¬ 
works. 


Octet 


98  - 


Bits 


8  7  6  5  *  3  2  1 


General  Format 
Identifier 
(See  Note  1) 

Logical 

Group 

Channel 

Number 

Logical 

Channel  Number 

0  0 

Packet  Type  Identifier 

0  0  11 

1  1 

Calling  DTE  address 
length 

Called  DTE  address 
length 

i 

1 

DTE  Address 

(See  Note  2) 

1 

i 

0  0 

0  0 

0  0 

Facility  length 

1  1 

•  1 

1  Facilities 

! _ 1 

1 

1 

| 

Called  User  Data 
(See  Botes  3  and  h) 

1 

1 

1 

1 

Bote  1:  Coded  0X01  (modulo  8)  or  0X10  (modulo  128). 

Bote  2:  The  figure  is  drawn  assuming  a  single  address 

is  present  consisting  of  an  odd  number  of  digits. 

Bote  3:  Bits  8  and  7  of  the  first  octet  of  the  Called 

User  Data  field  may  have  particular  significance 
(see  section  6.8,2.21, 

Bote  U:  Maximum  length  of  the  Called  User  Data  field  is 
128  octets. 


Figure  6.19/X.25  -  Call  accepted  and  call  connected  packet  format 
for  the  Fast  Select  facility 


Note:  When  a  virtual  call  is  being  established  between  two 

packet  mode  DTEs ,  the  network  does  not  act  on  any  part  of 
the  Called  User  Data  field,  unless  required  to  do  other¬ 
wise  by  an  appropriate  request  for  an  optional  user  facil¬ 
ity  on  a  per  call  basis.  Such  a  facility  is  for  further 
study. 

6.8.2. 3  Clear  Request  and  Clear  Indication  Packets 

Figure  6.20/X.25  illustrates  the  format  of  CLEAR  REQUEST  and 
CLEAR  INDICATION  packets  used  in  conjunction  with  the  Fast  Select 
facility  and  Fast  Select  Acceptance  facility  described  in  sec¬ 
tions  7.2.4  and  7.2.5. 

Description  of  the  Clearing  Cause  field  and  the  Diagnostic  Coda 
field  in  section  6.2.3  is  applied  to  this  section.  In  addition 
the  following  fields  may  follow  the  Diagnostic  Code  field  and  in 
such  cases  the  use  of  the  Diagnostic  Code  field  is  mandatory. 

Address  Lengths  Field 

Octet  6  consists  of  field  length  indicators  for  the  called  and 
calling  DTE  addresses.  Bits  4,  3,  2  and  1  indicate  the  length  of 
the  called  DTE  addresses  in  semi-octets.  Bits  8,  7,  6  and  5 
indicate  the  length  of  the  calling  DTE  address  in  semi-octets. 
Each  address  length  Indicator  is  binary  coded  and  bit  1  or  5  is 
the  low  order  bit  of  the  indicator. 

Note:  This  field  is  coded  with  all  Os.  Other  codings  are  for 
further  study. 

Address  Field 


Note:  Pending  the  further  study  indicated  above,  this  field  is 
not  present. 

Facility  Length  Pleld 

Bits  6,  5,  4,  3,  2  and  1  of  the  octet  following  the  Address  field 
indicate  the  length  of  the  Facility  field  in  octets.  The  facil¬ 
ity  length  indicator  is  binary  coded  and  bit  1  is  the  low  order 
bit  of  the  Indicator. 

Bits  8  and  7  of  this  octet  are  unassigned  and  set  to  0. 

Note:  This  field  is  coded  with  all  Os.  Other  codings  are  for 
further  study. 


et  1 


General  Fort,  a* 
1  der.4.  i  f  i  er 
(See  Note  1) 


Logical  Channel 
Group  Number 


Logical 

Channel  Number 

Packet  Type  Identifier 
1  0  0  1 

Clearing  Cause 

Diagnostic  Code 


Calling  DTE  address 
length 


Called  DTE  address 
length 


DTE  Address  (See  Note  2) 


Facilities 


Clear  User  Data 
(See  Note  3) 


Note  1:  Coded  0001  (modulo  8)  or  0010  (modulo  128). 

Note  2:  The  figure  is  drawn  assuming  a  single  address 

is  present  consisting  of  an  odd  number  of  digits. 
Note  3:  Maximum  length  of  the  Clear  User  Data  field 
is  128  octets. 


Figure  6.20/X.25  -  Clear  request  and  clear  indication 

packet  format  for  the  Fast  Select  facility 


K 


Facility  Field 

Note;  Pending  the  further  study  indicated  above,  this  field  is 
not  present. 

Clear  User  Data  Field 


Following  the  Facility  field,  the  Clear  User  Data  field  nay  be 
present  and  has  a  naxlmum  length  of  128  octets. 

Note:  At  present,  some  networks  require  the  Clear  User  Data 

field  to  contain  an  integral  number  of  octets  (see  see- 
tion  3,  Note  2) . 


7.  PROCEDURES  AND  FORMATS  FOR  OPTIONAL  USER  FACILITIES 

7. 1  Procedures  for  Optional  User  Facilities  Associated  with  Vir¬ 
tual  Circuit  and  Datagram  Services 

7.1.1  Extended  Packet  Sequence  Numbering 

Extended  Packet  Sequence  Numbering  is  an  optional  user  facility 
agreed  for  a  period  of  time.  It  applies  in  common  to  all  logical 
channels  at  the  DTE/DCE  interface. 

This  user  facility,  if  subscribed  to,  provides  sequence  numbering 
of  packets  performed  modulo  128.  In  the  absence  of  this  facil¬ 
ity,  the  sequence  numbering  of  packets  is  performed  modulo  8. 

7.1.2  Nonstandard  Default  Window  Sizes 

Nonstandard  Default  Window  Sizes  is  an  optional  user  facility 
agreed  for  a  period  of  time.  This  facility,  if  subscribed  to, 
provides  for  the  selection  of  default  window  sizes  from  the  list 
of  window  sizes  supported  by  the  Administration.  Some  networks 
may  constrain  the  default  window  sizes  to  be  the  same  for  each 
direction  of  transmission  across  the  DTE/DCE  interface.  In  the 
absence  of  this  facility,  the  default  window  sizes  are  2. 

Values  other  than  the  default  window  sizes  may  be  negotiated  for 
a  virtual  call  by  means  of  the  Flow  Control  Parameter  Negotiation 
facility  (see  section  7.2.2).  Values  other  than  the  default  win¬ 
dow  sizes  may  be  agreed  for  a  period  of  time  for  each  permanent 
virtual  circuit  and  each  datagram  logical  channel. 

7.1.3  Default  Throughput  Classes  Assignment 

Default  Throughput  Classes  Assignment  is  an  optional  user  facil¬ 
ity  agreed  for  a  period  of  time.  This  facility,  if  subscribed 
to,  provides  for  the  selection  of  default  throughput  classes  from 
the  list  of  throughput  classes  supported  by  the  Administration. 
Some  networks  may  constrain  the  default  throughput  classes  to  be 
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the  sane  for  each  direction  of  data  transmission.  In  the  absence 
of  this  facility,  the  '  ?ault  throughput  classes  correspond  to 
the  user  class  of  service  of  the  DTE  (see  section  7.4. 2.6)  but  do 
not  exceed  the  maximum  throughput  class  supported  by  the  network. 

The  default  throughput  classes  are  the  maximum  throughput  classes 
which  may  be  associated  with  any  virtual  call  at  the  DTE/DCE 
interface.  Values  other  than  the  default  throughput  classes  may 
be  negotiated  for  a  virtual  call  by  means  of  the  Throughput  Class 
Negotiation  facility  (see  section  7.2.3).  Values  other  than  the 
default  throughput  classes  may  be  agreed  for  a  period  of  time  for 
each  permanent  virtual  circuit  and  each  datagram  logical  channel. 

7.1.4  Packet  Retransmission 

Packet  Retransmission  is  an  optional  user  facility  agreed  for  a 
period  of  time.  It  applies  in  common  to  all  logical  channels  at 
the  DTE/DCE  interface. 

Note:  In  this  section,  the  term  "flow  controlled  packet"  refers 

to  the  DCE  DATA  packet  for  virtual  call  and  permanent  vir¬ 
tual  circuit  logical  channels  and  refers  to  the  DCE 
DATAGRAM  and  DATAGRAM  SERVICE  SIGNAL  packets  for  datagram 
logical  channels. 

This  user  facility,  if  subscribed  to,  allows  a  DTE  to  request 
retransmission  of  one  or  several  consecutive  flow  controlled 
packets  from  the  DCE  by  transferring  across  the  DTE/DCE  interface 
a  DTE  REJECT  packet  specifying  a  logical  channel  number  and  a 
sequence  number  P(R).  The  value  of  this  P(R)  should  be  within 
the  range  from  the  last  P(R)  received  by  the  DCE  up  to,  but  not 
including,  the  P(R)  of  the  next  flow  controlled  packet  to  be 
transmitted  by  the  DCE.  If  the  P(R)  is  outside  this  range,  the 
DCE  will  initiate  the  reset  procedure  with  the  cause  "Local  pro¬ 
cedure  error"  and  diagnostic  #2. 

When  receiving  a  DTE  REJECT  packet,  the  DCE  Initiates  on  the 
specified  logical  channel  retransmission  of  the  flow  controlled 
packets;  the  Packet  Send  Sequence  Numbers  of  which  are  starting 
from  P(R)  where  P(R)  is  indicated  in  the  DTE  REJECT  packet. 

Until  the  DCE  transfers  across  the  DTE/DCE  interface  a  flow  con¬ 
trolled  packet  with  a  Packet  Send  Sequence  Number  equal  to  the 
P(R)  indicated  in  the  DTE  REJECT  packet,  the  DCE  will  consider 
the  receipt  of  another  DTE  REJECT  packet  as  a  procedure  error  and 
reset  the  logical  channel. 

Additional  flow  controlled  packets  pending  initial  transmission 
may  follow  the  retransmitted  packet(s). 

A  DTE  receive  not  ready  situation  Indicated  by  the  transmission 
of  RNR  packet  is  cleared  by  the  transmission  of  a  DTE  REJECT 
packet . 
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The  conditions  under  which  the  DCE  ignores  a  DTE  REJECT  packet, 
or  considers  it  as  a  procedure  error,  are  those  described  for 
flow  control  packets  (see  Annex  3). 

7.1.5  Incoming  Calls  Barred 

Incoming  Calls  Barred  is  an  optional  user  facility  agreed  for  a 
period  of  time.  This  facility  applies  to  all  logical  channels 
used  at  the  DTE /DCE  interface  for  virtual  calls  and  datagrams. 

This  user  facility,  if  subscribed  to,  prevents  Incoming  virtual 
calls  and  datagrams  from  being  presented  to  the  DTE.  The  DTE  may 
originate  outgoing  virtual  calls  and  datagrams. 

Note;  Logical  channels  used  for  virtual  calls  retain  their  full 
duplex  capability.  Logical  channels  used  for  datagrams 
and  datagram  service  signals  retain  their  capability  to 
convey  datagram  service  signals. 

7.1.6  Outgoing  Calls  Barred 

Outgoing  Calls  Barred  is  an  optional  user  facility  agreed  for  a 
period  of  time.  This  facility  applies  to  all  logical  channels 
used  at  the  DTE/DC E  interface  for  virtual  calls  and  datagrams. 

This  user  facility,  if  subscribed  to,  prevents  the  DCE  from 

accepting  outgoing  virtual  calls  and  datagrams  from  the  DTE.  The 

DTE  may  receive  incoming  virtual  calls  and  datagrams.  t 

Note:  Logical  channels  used  for  virtual  calls  retain  their  full 

duplex  capability. 

7.1.7  One-way  Logical  Channel  Outgoing 

One-way  Logical  Channel  Outgoing  is  an  optional  user  facility 
agreed  for  a  period  of  time.  This  user  facility,  if  subscribed 
to,  restricts  the  logical  channel  use  to  originating  outgoing 
virtual  calls  or  datagrams  only. 

Note:  A  logical  channel  used  for  virtual  calls  retains  its  full 

duplex  capability.  A  logical  channel  used  for  datagrams 
and  datagram  service  signals  retains  its  capability  to 
convey  datagram  service  signals. 

The  rules  according  to  which  Logical  Channel  Group  Numbers  and 
Logical  Channel  Numbers  can  be  assigned  to  one-way  outgoing  logi¬ 
cal  channels  for  virtual  calls  are  given  in  Annex  1. 

Note:  If  all  the  logical  channels  for  virtual  calls  and 

datagrams  are  one-way  outgoing  at  a  DTE/DCE  Interface, 
the  effect  is  equivalent  to  the  Incoming  Calls  Barred 
facility  (see  section  7.1.5). 


■  vjf* 
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7.1.8  One-way  Logical  Channel  Incoming 

One-way  Logical  Channel  Incoming  is  an  optional  user  facility 
agreed  for  a  period  of  time.  This  user  facility,  if  subscribed 
to,  restricts  the  logical  channel  use  to  receiving  incoming  vir¬ 
tual  calls  or  datagrams  only. 

I 

Note :  A  logical  channel  used  for  virtual  calls  retains  its  full 

duplex  capability. 

The  rules  according  to  which  Logical  Channel  Group  Numbers  and 
Logical  Channel  Numbers  can  be  assigned  to  one-way  incoming  logi¬ 
cal  channels  for  virtual  calls  are  given  in  Annex  1. 

Note ;  If  all  the  logical  channels  for  virtual  calls  and 

datagrams  are  one-way  incoming  at  a  DTE/DCE  interface, 
the  effect  is  equivalent  to  the  Outgoing  Calls  Barred 
facility  (see  section  7.1,6). 

7.1.9  Closed  User  Group 

>  Closed  User  Group  is  an  optional  user  facility  agreed  for  a 

period  of  time  for  virtual  calls  or  datagrams.  This  facility,  if 
subscribed  to,  enables  the  DTE  to  belong  to  one  or  more  closed 
user  groups.  A  closed  user  group  permits  the  DTEs  belonging  to 
the  group  to  communicate  with  each  other,  but  precludes  communi¬ 
cation  with  all  other  DTEs. 

The  calling/source  DTE  should  specify  the  closed  user  group 
selected  for  a  virtual  call  or  datagram  using  the  optional  user 
facility  parameters  (see  section  7. 4. 2.1)  in  the  CALL  REQUEST  or 
DTE  DATAGRAM  packet. 

< 

The  closed  user  group  selected  for  a  virtual  call  or  datagram 
will  be  indicated  to  a  cal  led/destination  DTE  using  the  optional 
user  facility  parameters  (see  section  7. 4. 2.1)  in  the  INCOMING 
CALL  or  DCE  DATAGRAM  packet. 

When  a  DTE  only  belongs  to  one  closed  user  group  or  when  the  vir¬ 
tual  call  or  datagram  is  associated  with  the  DTE's  preferential 
closed  user  group,  this  indication  may  not  be  present  in  the  CALL 
REQUEST,  INCOMING  CALL,  DTE  DATAGRAM  or  DCE  DATAGRAM  packet. 

7.1.10  Closed  User  Group  with  Outgoing  Access 

Closed  User  Group  with  Outgoing  Access  is  an  optional  user  facil¬ 
ity  agreed  for  a  period  of  time  for  virtual  calls  or  datagrams. 

This  user  facility,  if  subscribed  to,  enables  the  DTE  to  belong  j 

to  one  or  more  closed  user  groups  (as  in  section  7.1.9)  and  to  i 

originate  virtual  calls  or  datagrams  to  DTEs  in  the  open  part  of  j 

the  network  and  to  DTEs  having  the  incoming  access  capability.  t 

> 

j  t 

*  ’ 


i 
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The  procedures  for  using  this  facility  are  the  same  as  those 
given  in  section  7.1.9.  However,  the  optional  user  facility 
parameters  may  not  be  present  when  originating  virtual  calls  or 
datagrams  to  DTEs  in  the  open  part  of  the  network  or  to  DTEs  hav¬ 
ing  the  incoming  access  capability. 

7.1.11  Closed  User  Group  with  Incoming  Access 

Closed  User  Group  with  Incoming  Access  is  an  optional  user  facil¬ 
ity  agreed  for  a  period  of  time  for  virtual  calls  or  datagrams. 
This  user  facility,  if  subscribed  to,  enables  the  DTE  to  belong 
to  one  or  more  closed  user  groups  (as  in  section  7.1.9)  and  to 
receive  incoming  calls  or  datagrams  from  DTEs  in  the  open  part  of 
the  network  and  from  DTEs  having  the  outgoing  access  capability. 

The  procedures  for  using  this  facility  are  the  same  as  those 
given  in  section  7.1.9.  However,  the  optional  user  facility 
parameters  may  not  be  present  when  receiving  incoming  calls  or 
datagrams  from  DTEs  in  the  open  part  of  the  network  or  from  DTEs 
having  the  outgoing  access  capability. 

7.1.12  Incoming  Calls  Barred  within  a  Closed  User  Group 

Incoming  Calls  Barred  within  a  Closed  User  Group  is  an  optional 
user  facility  agreed  for  a  period  of  time.  This  user  facility, 
if  subscribed  to  for  a  given  closed  user  group,  permits  the  DTE 
to  originate  virtual  calls  or  datagrams  to  DTEs  in  this  closed 
user  group,  but  precludes  the  reception  of  incoming  calls  or 
datagrams  from  other  DTEs  in  this  closed  user  group. 

The  procedures  for  using  this  facility  are  the  same  as  those 
given  in  sections  7.1.9,  7.1.10  and  7.1.11. 

7.1.13  Outgoing  Calls  Barred  within  a  Closed  User  Group 

Outgoing  Calls  Barred  within  a  Closed  User  Group  is  an  optional 
user  facility  agreed  for  a  period  of  time.  This  user  facility, 
if  subscribed  to  for  a  given  closed  user  group,  permits  the  DTE 
to  receive  virtual  calls  or  datagrams  from  other  DTEs  in  this 
closed  user  group,  but  prevents  the  DTE  from  originating  virtual 
calls  or  datagrams  to  other  DTEs  in  this  closed  user  group. 

The  procedures  for  using  this  facility  are  the  same  as  those 
given  in  sections  7.1.9,  7.1.10  and  7.1.11. 

7.1.14  Bilateral  Closed  User  Group 

Bilateral  Closed  User  Group  is  an  optional  user  facility  agreed 
for  a  period  of  time  for  virtual  calls  or  datagrams.  This  facil¬ 
ity,  if  subscribed  to,  enables  the  DTE  to  belong  to  one  or  more 
bilateral  closed  user  groups.  A  bilateral  closed  user  group  per¬ 
mits  a  pair  of  DTEs  who  bilaterally  agree  to  communicate  with 
each  other  to  do  so,  but  precludes  communication  with  all  other 
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DTEs. 

The  calling/source  DTE  should  specify  the  bilateral  closed  user 
group  selected  for  a  virtual  call  or  datagram  using  the  optional 
user  facility  parameters  (see  section  7. 4. 2. 2)  in  the  CALL 
REQUEST  or  DTE  DATAGRAM  packet.  The  called/destination  DTE 
address  length  shall  be  coded  all  zeros. 

The  bilateral  closed  user  group  for  a  virtual  call  or  datagram 
will  be  indicated  to  a  called/destination  DTE  using  the  optional 
user  facility  parameters  in  the  INCOMING  CALL  or  DCE  DATAGRAM 
packet . 


7.1.15  Bilateral  Closed  User  Group  with  Outgoing  Access 

Bilateral  Closed  User  Group  with  Outgoing  Access  is  an  optional 
user  facility  agreed  for  a  period  of  time  for  virtual  calls  or 
datagrams.  This  facility,  if  subscribed  to,  enables  the  DTE  to 
belong  to  one  or  more  bilateral  closed  user  groups  (as  in  section 
7.1.14)  and  to  originate  virtual  calls  or  datagrams  to  DTEs  in 
the  open  part  of  the  network. 

The  procedures  for  using  this  facility  are  the  same  as  those 
given  in  section  7.1.14. 

7.1.16  Reverse  Charging 

Reverse  Charging  is  an  optional  user  facility  which  can  be 
requested  by  a  DTE  for  a  given  virtual  call  or  for  a  datagram 
(see  section  7.4.2. 3). 

7.1.17  Reverse  Charging  Acceptance 

Reverse  Charging  Acceptance  is  an  optional  user  facility  agreed 
for  a  period  of  time. 

This  user  facility,  if  subscribed  to,  authorizes  the  DCE  to 
transmit  to  the  DTE  incoming  calls  or  datagrams  which  request  the 
Reverse  Charging  facility.  In  the  absence  ofthis  facility,  the 
DCE  will  not  transmit  to  the  DTE  incoming  calls  or  datagrams 
which  request  the  Reverse  Charging  facility. 

7.1.18  RPOA  Selection 

RPOA  Selection  is  an  optional  user  facility  which  may  be 
requested  by  a  DTE  for  a  given  virtual  call  or  for  a  datagram. 

This  user  facility,  when  requested,  provides  for  the  user  specif¬ 
ication  by  the  calling/source  DTE  of  a  particular  RPOA  transit 
network  through  which  the  call  or  datagram  is  to  be  routed  inter¬ 
nationally,  when  more  than  one  RPOA  transit  network  exists  at  an 
international  gateway  (see  section  7. 4. 2. 4). 
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7. 2  Procedures  for  Optional  User  Facilities  Only  Available  with 
Virtual  Circuit  Services 

7.2.1  Nonstandard  Default  Packet  Sizes 

Nonstandard  Default  Packet  Sizes  is  an  optional  user  facility 
agreed  for  a  period  of  time.  This  facility,  if  subscribed  to, 
provides  for  the  selection  of  default  packet  sizes  from  the  list 
of  packet  sizes  supported  by  the  Administration.  Some  networks 
may  constrain  the  packet  sizes  to  be  the  same  for  each  direction 
of  data  transmission  across  the  DTE/DCE  interface.  In  the 
absence  of  this  facility,  the  default  packet  sizes  are  12B 
octets. 

Note:  In  this  section,  the  term  "packet  sizes”  refers  to  the 

maximum  User  Data  field  lengths  of  DCE  DATA  and  DTE  DATA 
packets. 

Values  other  than  the  default  packet  sizes  may  be  negotiated  for 
a  virtual  call  by  means  of  the  Plow  Control  Parameter  Negotiation 
facility  (see  section  7.2.2).  Values  other  than  the  default 
packet  sizes  may  be  agreed  for  a  period  of  time  for  each  per¬ 
manent  virtual  circuit. 

7.2.2  Flow  Control  Parameter  Negotiation 

Flow  Control  Parameter  Negotiation  is  an  optional  user  facility 
agreed  for  a  period  of  time  which  can  be  used  by  a  DTE  for  vir¬ 
tual  calls.  This  facility,  if  subscribed  to,  permits  negotiation 
on  a  per  call  basis  of  the  flow  control  parameters.  The  flow 
control  parameters  considered  are  the  packet  and  window  sizes  at 
the  DTE/DCE  Interface  for  each  direction  of  data  transmission. 

Note:  In  this  section,  the  term  "packet  sizes"  refers  to  the 

maximum  User  Data  field  lengths  of  DCE  DATA  and  DTE  DATA 
packets. 

In  the  absence  of  the  Flow  Control  Parameter  Negotiation  facil¬ 
ity,  the  flow  control  parameters  to  be  used  at  a  particular 
DTE/DCE  Interface  are  the  default  packet  sizes  (see  section 
7.2.1)  and  the  default  window  sizes  (see  section  7.1.2). 

When  the  calling  DTE  has  subscribed  to  the  Flow  Control  Parameter 
Negotiation  facility,  it  may  separately  request  packet  sizes  and 
window  sizes  for  each  direction  of  data  transmission  (see  section 
7. 4. 2. 5).  If  a  particular  window  size  is  not  explicitly 
requested  in  a  CALL  REQUEST  packet,  the  DCE  will  assume  that  the 
default  window  size  was  requested.  If  a  particular  packet  size 
is  not  explicitly  requested,  the  DCE  will  assume  that  the  default 
packet  size  was  requested. 

When  a  called  DTE  has  subscribed  to  the  Plow  Control  Parameter 
Negotiation  facility,  each  INCOMING  CALL  packet  will  indicate  the 
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packet  and  window  sizes  from  which  DTE  negotiation  can  start.  No 
relationship  needs  to  exist  between  the  packet  and  window  sizes 
requested  in  the  CALL  REQUEST  packet  and  those  indicated  in  the 
INCOMING  CALL  packet.  The  called  DTE  may  request  window  and 
packet  sizes  with  facilities  in  the  CALL  ACCEPTED  packet.  The 
only  valid  facility  requests  in  the  CALL  ACCEPTED  packet,  as  a 
function  of  the  facility  indications  in  the  INCOMING  CALL  packet, 
are  given  in  Table  7.1/X.25.  If  the  facility  request  is  not  made 
in  the  CALL  ACCEPTED  packet,  the  DTE  is  assumed  to  have  accepted 
the  indicated  values  (regardless  of  the  defaul t  values)  . 

TABLE  7.1/X.25 

VALID  FACILITY  REQUESTS  IN  CALL  ACCEPTED  PACKET  IN  RESPONSE 
TO  FACILITY  INDICATIONS  IN  INCOMING  CALL  PACKET 


Facility  Indication 

Valid  Facility  Request  J 

W(indicated)  >  2 

W(lndicated)  ■  1 

P  (indicated)  ^128 

P( indicated)  <128 

W( indicated)  >  W( requested)  >  2 

W( requested)  ■  1  or  2 

P  (Indicated)  P  (requested)  £  128 

128  _>  P  (requested)  £  P (indicated) 

When  the  calling  DTE  has  subscribed  to  the  Flow  Control  Parameter 
Negotiation  facility,  every  CALL  CONNECTED  packet  will  indicate 
the  packet  and  window  sizes  to  be  used  at  the  DTE/DCE  interface 
for  the  call.  The  only  valid  facility  indications  in  the  CALL 
CONNECTED  packet,  as  a  function  of  the  facility  requests  in  the 
CALL  REQUEST  packet,  are  given  in  Table  7.2/X.2S. 
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TAMLF  7. 2/X . ? j 

VALTD  FACILITY  INDICATIONS  IN  CALL  CONNECTED  PACKET  IN 
RESPONSE  TO  FACILITY  REQUESTS  IN  CALL  REQUEST  PACKET 


Faci 1 i ty  Request 

w (  requested )  2 

W( requested)  ■  1 
P(requested)  £  128 
P  (requested)  <  128 


Valid  Facility  Indication 

W(  requested)  W(  indicated)  2 
W(indicated)  ■  1  or  2 
P  (requested)  P  (indicated)  >_  1  28 
128  >  P(indicated)  >  P(requested) 


The  network  may  have  constraints  requiring  the  flow  control 
parameters  used  for  *»  call  to  be  modified  before  indicating  them 
to  the  DTE  in  the  INCOMING  CALL  packet  or  CALL  CONNECTED  packet; 
e.g.,  the  ranges  of  parameter  values  available  on  various  net* 
works  may  differ. 

Window  and  packet  sizes  need  not  be  the  same  at  each  end  of  a 
virtual  call. 

The  role  of  the  DCE  in  negotiating  the  flow  control  parameters 
may  be  network  dependent. 

7.2.3  Throughput  Class  Negotiation 

Throughput  Class  Negotiation  is  an  optional  user  facility  agreed 
for  a  period  of  time  which  can  be  used  by  a  DTE  for  virtual 
calls.  This  facility,  if  subscribed  to,  permits  negotiation  on  a 
per  call  basis  of  the  throughput  classes.  The  throughput  classes 
are  considered  independently  for  each  direction  of  data  transmis¬ 
sion. 

Default  values  are  agreed  between  the  DTE  and  the  Administration 
(see  section  7.1.3).  The  default  values  correspond  to  the  max¬ 
imum  throughput  classes  which  may  be  associated  with  any  virtual 
call  at  the  DTE/DCE  interface. 

When  the  calling  DTE  has  subscribed  to  the  Throughput  Class  Nego¬ 
tiation  facility,  it  may  separately  request  the  throughput 
classes  of  the  virtual  call  in  the  CALL  REQUEST  packet  (see  sec¬ 
tion  7. 4. 2. 6).  If  particular  throughput  classes  are  not 
requested,  the  DCE  will  assume  the  default  values. 

When  a  called  DTE  has  subscribed  to  the  Throughput  Class  Negotia¬ 
tion  facility,  each  INCOMING  CALL  packet  will  indicate  the 
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throughput  classes  from  which  DTE  negotiation  may  start.  These 
throughput  classes  are  lower  or  equal  to  the  ones  selected  at  the 
calling  DTE/D^E  interface,  either  explicitly,  or  by  default  if 
the  calling  DTE  has  not  subscribed  to  the  Throughput  Class  Nego¬ 
tiation  facility  or  has  not  explicitly  requested  throughput  class 
values  in  the  CALL  REQUEST  packet.  These  throughput  classes 
indicated  to  the  called  DTE  will  also  not  be  higher  than  the 
default  throughput  classes,  respectively  for  each  direction  of 
transmission,  at  the  callinq  and  the  called  DTE/DCE  interfaces. 
They  may  be  further  constrained  by  internal  limitations  of  the 
network . 

The  called  DTE  may  request  with  a  facility  in  the  CALL  ACCEPTED 
packet  the  throughput  classes  that  should  finally  apply  to  the 
virtual  call.  The  only  valid  throughput  classes  in  the  CALL 
ACCEPTED  packet  are  lower  than  or  equal  to  the  ones  (respec¬ 
tively)  indicated  in  the  INCOMING  CALL  packet.  If  the  called  DTE 
does  not  make  any  throughput  class  facility  request  in  the  CALL 
ACCEPTED  packet,  the  throughput  classes  finally  applying  to  the 
virtual  call  will  be  the  ones  indicated  in  the  INCOMING  CALL 
packet . 

If  the  called  DTE  has  not  subscribed  to  the  Throughput  Class 
Negotiation  facility,  the  throughput  classes  finally  applying  to 
the  virtual  call  are  less  than  or  equal  to  the  ones  selected  at 
the  calling  DTE/DCE  interface,  and  less  than  or  equal  to  the 
default  values  defined  at  the  called  DTE/DCE  interface. 

When  the  calling  DTE  has  subscribed  to  the  Throughput  Class  Nego¬ 
tiation  facility,  every  CALL  CONNECTED  packet  will  Indicate  the 
throughput  classes  finally  applying  to  the  virtual  call. 

When  neither  the  calling  DTE  nor  the  called  DTE  has  subscribed  to 
the  Throughput  Class  Negotiation  facility,  the  throughput  classes 
applying  to  the  virtual  call  will  not  be  higher  than  the  ones 
agreed  as  defaults  at  the  calling  and  called  DTE/DCE  Interfaces. 
They  may  be  further  constrained  to  lower  values  by  the  network, 
e.g.,  for  international  service. 

Note  1:  Since  both  Throughput  Class  Negotiation  and  Plow  Control 
Parameter  Negotiation  (see  section  7.2.2)  facilities  can 
be  applied  to  a  single  call,  the  achievable  throughput 
will  depend  on  how  users  manipulate  the  D  bit. 

Note  2:  Users  are  cautioned  that  the  choice  of  too  small  a  win- 
“  dow  and  packet  size  of  a  DTE/DCE  interface  (made  by  use 

of  the  Flow  Control  Parameter  Negotiation  facility)  may 
adversely  affect  the  attainable  throughput  class  of  a 
virtual  call.  This  is  likewise  true  of  flow  control 
mechanisms  adopted  by  the  DTE  to  control  data  transmis¬ 
sion  from  the  DCS. 
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7.2.4  Fast  Select 

Fast  Select  is  an  optional  user  facility  which  may  be  requested 
by  a  DTE  for  a  given  virtual  call. 

DTEs  can  request  the  Fast  Select  facility  on  a  per  call  basis  by 
means  of  an  appropriate  facility  request  (see  section  7. 4. 2.7)  in 
a  CALL  REQUEST  packet  using  any  logical  channel  which  has  been 
assigned  to  virtual  calls. 

The  Fast  Select  facility,  if  requested  in  the  CALL  REQUEST  packet 
and  if  it  indicates  no  restriction  on  response,  allows  this 
packet  to  contain  a  Call  User  Data  field  of  up  to  126  octets  and 
authorises  the  DCE  to  transmit  to  the  DTE,  during  the  DTE  waiting 
state,  a  CALL  CONNECTED  packet  with  a  Called  User  Data  field  of 
up  to  128  octets  or  a  CLEAR  INDICATION  packet  with  a  Clear  User 
Data  field  of  up  to  126  octets. 

The  Fast  Select  facility,  if  requested  in  the  CALL  REQUEST  packet 
and  if  it  indicates  restriction  on  response,  allows  this  packet 
to  contain  a  Call  User  Data  field  of  up  to  123  octets  and  author¬ 
izes  the  DCE  to  transmit  to  the  DTE,  during  the  DTE  waiting 
state,  a  CLEAR  INDICATION  packet  with  a  Clear  User  Data  field  of 
uo  to  128  octets;  the  DCE  would  not  be  authorized  to  transmit  a 
CALL  CONNECTED  packet. 

Where  a  DTE  requests  the  Fast  Select  facility  in  a  CALL  REQUEST 
packet,  the  INCOMING  CALL  packet  should  be  only  delivered  to  the 
called  DTE  if  that  DTE  has  subscribed  to  the  Fast  Select  Accep¬ 
tance  facility  (see  section  7.2.5). 

If  the  called  DTE  has  subscribed  to  the  Fast  Select  Acceptance 
facility,  it  will  be  advised  that  the  Fast  Select  facility,  and 
an  indication  of  whether  or  not  there  is  a  restriction  on  the 
response,  has  been  requested  through  the  inclusion  of  the 
appropriate  facility  in  the  INCOMING  CALL  packet. 

If  the  called  DTE  has  not  subscribed  to  the  Fast  Select  Accep¬ 
tance  facility,  an  INCOMING  CALL  packet  with  the  Fast  Select 
facility  requested  will  not  be  transmitted  and  a  CLEAR  INDICATION 
packet  with  the  cause  "Fast  select  acceptance  not  subscribed” 
will  be  returned  to  the  calling  DTE. 

The  presence  of  the  Fast  Select  facility  indicating  no  restric¬ 
tion  on  response  in  an  INCOMING  CALL  packet  permits  the  DTE  to 
issue  as  a  direct  response  to  this  packet  a  CALL  ACCEPTED  packet 
with  a  Called  User  Data  field  of  up  to  128  octets  or  a  CLEAR 
REQUEST  packet  with  a  Clear  User  Data  field  of  up  to  128  octets. 

The  presence  of  the  Fast  Select  facility  indicating  restriction 
on  response  in  an  INCOMING  CALL  packet  permits  the  DTE  to  issue 
as  a  direct  response  to  this  packet  a  CLEAR  REQUEST  packet  with  a 
Clear  User  Data  field  of  up  to  128  octets;  the  DTE  would  not  be 


authorized  to  send  a  CALL  ACCEPTED  packet. 

The  possibility  to  send  a  CLEAR  REQUEST  packet  with  a  Clear  User 
Data  field  up  to  128  octets  at  any  time  instead  of  just  in  the 
DCE  WATTING  state  (p?)  is  for  further  study. 

Note ;  The  Call  User  Data  field,  the  Called  User  Data  field  and 
the  Clear  User  Data  field  will  not  be  fragmented  for 
delivery  across  the  DTE/DCE  interface. 

The  significance  of  the  CALL  CONNECTED  packet  and  the  CLEAR  INDI¬ 
CATION  packet  with  the  cause  "DTE  originated*  as  a  direct 
response  to  the  CALL  REQUEST  packet  with  the  Fast  Select  facility 
is  that  the  CALL  REQUEST  packet  with  the  data  field  has  been 
received  by  the  called  DTE. 

All  other  procedures  of  a  call  in  which  the  Fast  Select  facility 
has  been  requested  are  the  same  as  those  of  a  virtual  call. 

7.2.5  Fast  Select  Acceptance 

Fast  Select  Acceptance  is  an  optional  user  facility  agreed  for  a 
period  of  time.  This  user  facility,  if  subscribed  to,  authorizes 
the  DCE  to  transmit  to  the  DTE  incoming  calls  which  request  the 
Fast  Select  facility.  In  the  absence  of  this  facility,  the  DCE 
will  not  transmit  to  the  DTE  incoming  calls  which  request  the 
Fast  Select  facility. 

7.2.6  D  Bit  Modification 

D  Bit  Modification  is  an  optional  user  facility  agreed  for  a 
period  of  time.  This  facility  applies  to  all  virtual  calls  and 
permanent  virtual  circuits  at  the  DTE/DCE  interface.  This  facil¬ 
ity  is  only  Intended  for  use  by  those  pre  D  bit  DTEs  which  were 
designed  for  operation  on  Public  Data  Networks  that  support  end- 
to-end  P (R )  significance.  It  allows  these  DTEs  to  continue  to 
operate  with  end-to-end  P(R)  significance  within  a  national  net¬ 
work  after  the  network  supports  the  delivery  confirmation  (D  bit) 
procedure. 

This  facility,  when  subscribed  to,  will  for  communications  within 
the  national  network: 

(a)  change  the  value  of  the  D  bit  from  0  to  1  in  all  CALL 
REQUEST,  CALL  ACCEPTED  and  DTE  DATA  packets  received 
from  the  DTE,  and 

(b)  set  the  D  bit  to  0  in  all  INCOMING  CALL,  CALL  CONNECTED 
and  DCE  DATA  packets  transmitted  to  the  DTE. 

For  international  operation,  conversion  (b)  above  applies  and 
conversion  (a)  above  does  not  apply.  Other  conversion  rules  for 
International  operation  are  for  bilateral  agreement  between 
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Administrations  . 

7. 3  Procedures  for  Optional  User  Facilities  Only  Available  with 
Datagram  Service 

7.3.1  Abbreviated  Address 

Abbreviated  Address  an  optional  user  facility  agreed  for  a  period 
of  time.  This  facility  permits  encoding  of  addresses  into 
shorter  representations  as  agreed  between  the  Administration  and 
DTE.  Initially  this  facility  is  restricted  to  a  It  1  mapping  of 
single  addresses,  but  1:N  mapping  for  multiple  addresses  is  for 
further  study. 

7.3.2  Datagram  Queue  Length  Selection 

Datagram  Queue  Length  Selection  is  an  optional  user  facility 
agreed  for  a  period  of  time  for  each  datagram  logical  channel. 
This  facility  enables  selection  of  the  number  of  datagram  and 
datagram  service  signal  packets  that  will  be  stored  in  a  queue  by 
the  destination  DCE  when  the  rate  of  arrival  of  packets  at  the 
destination  DCE  from  other  sources  exceeds  the  rate  of  delivery 
of  packets  to  the  destination  DTE. 

7.3.3  Datagram  Service  Signal  Logical  Channel 

Datagram  Service  Signal  Logical  Channel  is  an  optional  user 
facility  agreed  for  a  period  of  time.  This  facility  provides  a 
separate  logical  channel  for  the  DTE  to  receive  only  datagram 
service  signals.  This  enables  the  DTE  to  separately  flow  control 
datagram  service  signal  packets  from  the  datagram  packets. 

7.3.4  Datagram  Non-delivery  Indication 

Datagram  Non-delivery  Indication  is  an  optional  user  facility 
which  may  be  agreed  for  a  period  of  time  or  selected  on  a  per' 
datagram  basis  (see  section  7.4. 2.8). 

This  user  facility,  when  requested,  provides  for  a  non-delivery 
Indication  service  signal  generated  by  the  network  when  a 
datagram  cannot  be  delivered  to  the  destination  DTE. 

7.3.5  Datagram  Delivery  Confirmation 

Datagram  Delivery  Confirmation  is  an  optional  user  facility  which 
may  be  agreed  for  a  period  of  time  or  selected  on  a  per-datagram 
basis  (see  section  7. 4. 2. 9). 

This  user  facility,  when  requested,  provides  for  a  delivery  con¬ 
firmation  service  signal  generated  by  the  network  after  the 
datagram  has  been  accepted  by  the  destination  DTE. 


114- 


7. 4  Formats  for  Optional  User  Facilities 
7.4.1  General 

The  Facility  field  is  present  only  when  a  DTE  is  using  an 
opti  onal  user  facility  requiring  some  indication  in  the  CALL 
REQUEST ,  INCOMING  CALL,  CALL  ACCEPTED,  CALL  CONNECTED,  CLEAR 
REQUEST,  CLEAR  INDICATION,  DTE  DATAGRAM  or  DCE  DATAGRAM  packet. 

The  Facility  field  contains  one  or  more  facility  elements.  The 
first  octet  of  each  facility  element  contains  a  facility  code  to 
indicate  the  facility  or  facilities  requested. 

Notes  The  action  taken  by  the  DCE  when  a  facility  code  appears 
more  than  once  is  for  further  study. 

The  facil ity  codes  are  divided  into  four  classes,  by  making  use 
of  bits  8  and  7  of  the  facility  code  field,  in  order  to  specify 
facility  parameters  consisting  of  1,  2,  3,  or  a  variable  number 
of  octets.  The  general  class  coding  of  the  facility  code  field 
is  shown  below. 


bit  87654321 

CLASS  A  OOXXXXXX  for  single  octet  parameter  field 

CLASS  B  01XXXXXX  for  double  octet  parameter  field 

CLASS  C  10XXXXXX  for  triple  octet  parameter  field 

CLASS  D  11XXXXXX  for  variable  length  parameter  field 

Por  class  D  the  octet  following  the  facility  code  indicates  the 
length,  in  octets,  of  the  facility  parameter  field.  The  facility 
parameter  field  length  is  binary  coded  and  bit  1  is  the  low  order 
bit  of  this  Indicator. 

The  formats  for  the  four  classes  are  shown  below. 
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CLASS  A 


87654321 


0 

0OXXXXXX 

1 

Facility  parameter  field 

CLASS  C 

8  7  6  5  4  3  2  1 

0 

10XXXXXX 

1 

Facility 

2 

parameter 

3 

field 

CLASS  B 


8  7  6  5  4 

3 

2 

1 

0 

0  1  X  X  X 

X 

X 

X 

1 

Fact  1 ity 

2 

parameter 

field 

- 

CLASS  D 

8  7  6  5  4 

3 

2 

1 

0 

1  1  X  X  X 

X 

X 

3 

1 

Facility  parameter 
field  length _ _ 

2 

Facil ity 

l 

1  parameter 

1  field 

I 

i 

i 

1 

C 


The  facility  code  field  is  binary  coded  and,  without  extension, 
provides  for  a  maximum  of  64  facility  codes  for  classes  A,  B  and 
C  and  63  facility  codes  for  class  D  giving  a  total  of  255  facil¬ 
ity  codes. 

Facility  code  11111111  is  reserved  for  extension  of  the  facility 
code.  The  octet  following  this  octet  indicates  an  extended 
facility  code  having  the  format  A,  B,  C  or  D  as  defined  above. 
Repetition  of  facility  code  11111111  is  permitted  and  thus  addi¬ 
tional  extensions  result. 

The  coding  of  the  facility  parameter  field  is  dependent  on  the 
facility  being  requested. 

A  facility  code  may  be  assigned  to  identify  a  number  of  specific 
facilities,  each  having  a  bit  in  the  parameter  field  indicating 
facility  requested/facil ity  not  requested.  In  this  situation, 
the  parameter  field  is  binary  encoded  with  each  bit  position 
relating  to  a  specific  facility.  A  0  indicates  that  the  facility 
related  to  the  particular  bit  is  not  requested  and  a  1  indicates 
that  the  facility  related  to  the  particular  bit  is  requested. 
Parameter  bit  positions  not  assigned  to  a  specific  facility  are 
set  to  zero.  If  none  of  the  facilities  represented  by  the  facil¬ 
ity  code  are  requested  for  a  virtual  call  or  datagram,  the  facil¬ 
ity  code  and  its  associated  parameter  field  need  not  be  present. 
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A  Facility  Marker,  consisting  of  a  single  octet  pair,  is  used  to 
separate  requests  for  X. 25  facilities,  as  defined  in  this  sec¬ 
tion,  from  requests  for  non-X.25  facilities  that  may  also  be 
offered  by  an  Administration.  The  first  octet  is  a  facility  code 
and  is  set  to  zero  and  the  second  octet  is  the  facility  parameter 
field. 

The  coding  of  the  parameter  field  will  be  either  all  zeros  or  all 
ones  depending  on  whether  the  facility  requests  following  the 
marker  refer  to  facilities  offered  by  the  calling/source  or 
called/destination  network,  respectively.  For  intra-network  vir¬ 
tual  calls  or  datagrams,  the  parameter  field  should  be  all  zeros. 

Requests  for  non-X.25  facilities  offered  by  the  calling/source 
and  called/destination  networks  may  be  simultaneously  present 
within  the  facility  field  and  in  such  cases  two  Facility  Markers 
will  be  required  with  parameter  fields  coded  as  described  above. 

within  the  facility  field,  requests  for  X. 25  facilities  will  pre¬ 
cede  all  requests  for  non-X.25  facilities  and  Facility  Markers 
need  only  be  included  when  requests  for  non-X.25  facilities  are 
present . 

7.4.2  Coding  of  Facility  Field  for  Particular  Facilities 

7. 4. 2.1  Coding  of  Closed  User  Group  Facility 

The  coding  of  the  facility  code  field  and  the  format  of  the 
facility  parameter  field  for  Closed  User  Group  are  the  same  in 
CALL  REQUEST,  INCOMING  CALL,  DTE  DATAGRAM  and  DCE  DATAGRAM  pack¬ 
ets  . 

Facility  Code  Field 

The  coding  of  the  facility  code  field  for  Closed  User  Groups  is: 
bit:  B7654321 
code:  0000001  1 

Facility  Parameter  Field 


The  index  to  the  Closed  User  Group  selected  for  the  virtual  call 
or  datagram  is  in  the  form  of  two  decimal  digits.  Each  digit  is 
coded  in  a  semi-octet  in  binary  coded  decimal  with  bit  5  being 
the  low  order  bit  of  the  first  digit  and  bit  1  being  the  low 
order  bit  of  the  second  digit. 


Indexes  to  the  same  Closed  User  Group  at  different  DTE/DCE  inter¬ 
faces  may  be  different. 
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7. 4. 2. 2  Coding  of  Bilaterial  Closed  User  Group  Facility 

The  coding  of  the  facility  code  field  and  the  format  of  the 
facility  parameter  field  for  Bilateral  Closed  User  Group  are  the 
same  in  CALL  REQUEST,  INCOMING  CALL,  DTE  DATAGRAM  and  DCE 
DATAGRAM  packets. 

Facility  Code  Field 

The  coding  of  the  facility  code  field  for  Bilateral  Closed  User 
Group  is: 


bit:  8  7  6  5  4  3  2  1 
code:  01000001 
Facility  Parameter  Field 

The  index  to  the  Bilateral  Closed  User  Group  selected  for  the 
virtual  call  or  datagram  is  In  the  form  of  4  decimal  digits. 

Each  digit  is  coded  in  a  semi-octet  in  binary  coded  decimal  with 
bit  5  of  the  first  octet  being  the  low  order  bit  of  the  first 
digit,  bit  1  of  the  first  octet  being  the  low  order  bit  of  the 
second  digit,  bit  S  of  the  second  octet  being  the  low  order  bit 
of  the  third  digit,  and  bit  1  of  the  second  octet  being  the  low 
order  bit  of  the  fourth  digit. 

Indexes  to  the  same  Bilateral  Closed  User  Group  at  different 
DTE/DCE  interfaces  may  be  different. 

7. 4. 2. 3  Coding  of  Reverse  Charging  Facility 

The  coding  of  the  facility  code  and  parameter  fields  for  Reverse 
Charging  is  the  same  in  CALL  REQUEST,  INCOMING  CALL,  DTE 
DATAGRAM,  and  DCE  DATAGRAM  packets. 

Facility  Code  Field 

The  coding  of  the  facility  code  field  for  Reverse  Charging  is: 


bit:  87654321 
code:  00000001 


Facility  Parameter  Field 

The  coding  of  the  facility  parameter  field  is: 


lift  - 


bit  1  a  0  for  Reverse  Charging  not  requested 

Lit  1*1  for  Reverse  Charging  requested 

Note i  Bits  6,  5,  4,  3  and  2  may  be  used  for  other  facilities;  if 
not,  they  are  set  to  0.'  Use  of  bits  R  and  7  are  described 
in  section  7. 4. 2, 7. 

7. 4. 2. 4  Coding  of  RPOA  Selection  Facility 

The  coding  of  the  facility  code  and  parameter  fields  for  RPOA 
Selection  is  the  same  in  CALL  REQUEST,  INCOMING  CALL,  DTE 
DATAGRAM  and  DCE  DATAGRAM  packets. 

Facility  Code  Field 

The  coding  of  the  facility  code  field  for  RPOA  Selection  is: 
bit:  87654321 

code:  01000100 

Facility  Parameter  Field 

The  parameter  field  contains  the  Data  Network  Identification  Code 
for  the  requested  RPOA  transit  network,  and  is  in  the  form  of  4 
decimal  digits. 

Each  digit  is  coded  in  a  semi-octet  in  binary  coded  decimal  with 
bit  5  of  the  first  octet  being  the  low  order  bit  of  the  first 
digit,  bit  1  of  the  first  octet  being  the  low  order  bit  of  the 
second  digit,  bit  5  of  the  second  octet  being  the  low  order  bit 
of  the  third  digit,  and  bit  1  of  the  second  octet  being  the  low 
order  bit  of  the  fourth  digit. 

7. 4. 2. 5  Coding  of  the  Flow  Control  Parameter  Negotiation  Facll- 

n* 

7. 4. 2. 5.1  Coding  for  Packet  Sizes 

The  coding  of  the  facility  code  field  and  the  format  of  the 
facility  parameter  field  for  packet  sizes  are  the  same  in  CALL 
REQUEST,  INCOMING  CALL,  CALL  ACCEPTED,  and  CALL  CONNECTED  pack¬ 
ets. 

Facility  Code  Field 

The  coding  of  the  facility  code  field  for  packet  sizes  is: 
bit:  87654321 


code: 


0  1  0  0  0  0  1  0 
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Facility  Parameter  Field 

The  packet  size  for  the  direction  of  transmission  from  the  called 
DTE  is  indicated  in  bits  4,  3,  2,  and  1  of  the  first  octet.  The 
packet  size  for  the  direction  of  transmission  from  the  calling 
DTE  is  indicated  in  bits  4,  3,  2,  and  1  of  the  second  octet. 

Bits  5,  6,  7  and  8  of  each  octet  must  be  zero. 

The  four  bits  indicating  each  packet  size  are  binary  coded  and 
express  the  logarithm  base  2  of  the  number  of  octets  of  the  max¬ 
imum  packet  size. 

Networks  may  offer  values  from  4  to  10,  corresponding  to  packet 
sizes  of  16,  32,  64,  128,  256,  512,  or  1024,  or  a  subset  of  these 
values.  All  Administrations  will  provide  a  packet  size  of  128. 

7. 4. 2. 5. 2  Coding  for  Window  Sizes 

The  coding  of  the  facility  code  field  and  the  format  of  the 
facility  parameter  field  for  window  sizes  are  the  same  in  CALL 
REQUEST,  INCOMING  CALL,  CALL  ACCEPTED,  and  CALL  CONNECTED  pack¬ 
ets  . 

Facility  Code  Field 

The  coding  of  the  facility  code  field  for  window  sizes  is: 
bit:  87654321 
code:  01000011 

Facility  Parameter  Field 

The  window  size  for  the  direction  of  transmission  from  the  called 
DTE  is  indicated  in  bits  7  to  1  of  the  first  octet.  The  window 
size  for  the  direction  of  transmission  from  the  calling  DTE  is 
indicated  in  bits  7  to  1  of  the  second  octet.  Bit  8  of  each 
octet  must  be  zero. 

The  bits  indicating  each  window  size  are  binary  coded  and  express 
the  size  of  the  window.  A  value  of  zero  is  not  allowed. 

Window  sizes  of  8  to  127  are  only  valid  for  calls  which  employ 
extended  numbering.  The  ranges  of  values  allowed  by  a  network 
for  calls  with  normal  numbering  and  extended  numbering  are  net¬ 
work  dependent.  All  Administrations  will  provide  a  window  size 
of  2. 
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7. 4. 2. 6  Coding  of  Throughput  Class  Negotiation  Facility 

The  coding  of  the  facility  code  field  and  the  format  of  the 
facility  parameter  field  for  Throughput  Class  Negotiation  are  the 
sane  in  CALL  REQUEST,  INCOMING  CALL,  CALL  ACCEPTED  and  CALL  CON¬ 
NECTED  packets. 

Facility  Code  Field 

The  coding  of  the  facility  code  field  for  Throughput  Class  Nego¬ 
tiation  is: 

bit:  87654321 


code:  00000010 
Facility  Parameter  Field 

The  throughput  class  for  transmission  from  the  calling  DTE  is 
indicated  in  bits  4,  3,  2  and  1.  The  throughput  class  for 
transmission  from  the  called  DTE  Is  indicated  in  bits  8,  7,  6  and 
5. 


The  four  bits  indicating  each  throughput  class  are  binary  coded 
and  correspond  to  throughput  classes  as  indicated  below. 


« 


bit:  4321 
or  bit:  8765 

0  0  0  0 
0  0  0  1 
0  0  10 
0  0  11 
0  10  0 
0  10  1 
0  110 
0  111 
10  0  0 
10  0  1 
10  10 
10  11 
110  0 
110  1 
1110 
1111 


Throughput  class 
(bits  per  second) 

Reserved 

Reserved 

Reserved 

75 

150 

300 

600 

1,200 

2,400 

4,800 

9,600 

19,200 

48,000 

Reserved 

Reserved 

Reserved 


Ceding  of  Fast  Select  facility 


•v*  the  facility  code  and  parameter  fie?  "s  for  Fast 

•  ease  In  CALL  REQUEST  and  INCOMING  CALL  packets. 
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Facility  Code  Field 

The  coding  of  the  facility  code  field  for  Fast  Select  is: 
bit:  87654321 
code:  00000001 

Facility  Parameter  Field 

The  coding  of  the  facility  parameter  field  is: 

bit  8=0  and  bit  7  *  0  or  1  for  Fast  Select  not  requested 

bit  8  =  1  and  bit  7=0  for  Fast  Select  requested  with  no 

restriction  on  response 

bit  8=1  and  bit  7*1  for  Fast  Select  requested  with 

restriction  on  response 

Note:  Bits  6,  5,  4,  3  and  2  may  be  used  for  other  facilities;  if 
not,  they  are  set  to  0.  Use  of  bit  1  is  described  in  sec¬ 
tion  7 . 4.  2.  3. 

7. 4. 2. 3  Coding  of  Datagram  Non-delivery  Indication  Facility 

The  coding  of  the  facility  code  and  parameter  fields  is  the  same 
in  the  DTE  DATAGRAM  and  DCE  DATAGRAM  packets. 

Facility  Code  Field 

The  coding  of  the  facility  code  field  for  Datagram  Non-delivery 
Indication  is: 

bit:  87654321 

code:  00000110 

Facility  Parameter  Field 

The  coding  of  the  facility  parameter  field  is: 

bit  2=0  for  Datagram  Non-delivery  Indication  not  requested 

bit  2=1  for  Datagram  Non-delivery  Indication  requested 

Note :  Bits  8,  7,  6,  5,  4,  and  3  may  be  used  for  other  facili¬ 
ties;  if  not,  they  are  set  to  0.  use  of  bit  1  is 
described  in  section  7.4.2.S. 
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7. 4. 2.9  Coding  of  Datagram  Delivery  Confirmation  Facility 

The  coding  of  the  facility  code  and  parameter  fields  is  the  sane 
in  the  DTE  DATAGRAM  and  DC"  DATAGRAM  packets. 

Facility  Code  Field 

The  coding  of  the  facility  code  field  for  Datagram  Delivery  Con¬ 
firmation  is: 

bit:  87654321 

code:  00000110 

Facility  Parameter  Field 

The  coding  of  the  facility  parameter  field  is: 

bit  1*0  for  Datagram  Delivery  Confirmation  not  requested 

bit  1*1  for  Datagram  Delivery  Confirmation  requested 

Note:  Bits  8,  1,  6,  5,  4,  and  3  may  be  used  for  other  facili¬ 
ties;  if  not,  they  are  set  to  0.  Use  of  bit  2  is 
described  in  section  7. 4. 2. 8. 
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ANNEX  1 

(to  Recommendation  X.25) 

RANGE  OP  LOGICAL  CHANNELS  USED  FOR  VIRTUAL  CALLS, 
PERMANENT  VIRTUAL  CIRCUITS  AND  DATAGRAMS 

In  the  case  of  a  single  logical  channel  DTE,  logical  channel  1 
will  be  used. 

For  each  multiple  logical  channel  DTE/DCE  interface,  a  range  of 
logical  channels  will  be  agreed  upon  with  the  Administration 
according  to  the  following  figure: 


HTC 

LOC 


* 


>• 


HOC  I 
4095J 


4 


Permanent  Virtual  Circuits 
and  Datagrams 

One  way  j 
incoming 


Two  way 


y  Virtual 
I  Calls 


One  way 
outgoing 


where : 


Logical  channels  1  to  LIC-1:  range  of  logical  channels  which  may 
be  assigned  to  permanent  virtual  circuits  and  datagrams. 


Logical  channels  LIC  to  HIC:  range  of  logical  channels  which  are 
assigned  to  one-way  incoming  logical  channels  for  virtual  calls 
(see  section  7.1.6). 


Logical  channels  LTC  to  HTC:  range  of  logical  channels  which  are 
assigned  to  two-way  logical  channels  for  virtual  calls. 


Logical  channels  LOC  to  HOC:  range  of  logical  channels  which  are 
assigned  to  one-way  outgoing  logical  channels  for  virtual  calls 
(see  section  7.1.7). 


Logical  channels  HIC+1  to  LTC-1,  HTC+1  to  LOC-1,  and  HOC+1  to 
4095  are  non-assigned  logical  channels. 
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Note  I;  The  reference  to  the  numbers  of  logical  channels  is  made 
according  to  a  set  of  contiguous  numbers  from  0  (lowest) 
to  4095  (highest)  using  12  bits  made  up  of  the  4  bits  of 
the  Logical  Channel  Group  Number  (see  section  6.1.2)  and 
the  8  bits  of  the  Logical  Channel  Number  (see  section 
6.1.3).  The  numbering  is  binary  coded  using  bit  posi¬ 
tions  4  through  1  of  octet  1  followed  by  bit  positions  8 
through  1  of  octet  2  with  bit  1  of  octet  2  as  the  low 
order  bit. 

Note_2s  All  logical  channel  boundaries  are  agreed  with  the 
Administration  for  a  period  of  time. 

Note  3:  In  order  to  avoid  frequent  rearrangement  of  logical 

channels,  not  all  logical  channels  within  the  range  for 
permanent  virtual  circuits  or  datagrams  are  necessarily 
assig  ned . 

Note  4:  In  the  absence  of  permanent  virtual  circuits  and 

datagram  channels,  logical  channel  1  is  available  for 
LIC.  In  the  absence  of  permanent  virtual  circuits, 
datagram  channels  and  one-way  incoming  logical  channels, 
logical  channel  1  is  available  for  LTC.  In  the  absence 
of  permanent  virtual  circuits,  datagram  channels,  one 
way  Incoming  logical  channels  and  two-way  logical  chan¬ 
nels,  logical  channel  1  is  available  for  LOC. 

Note  5;  DCE  search  algorithm  for  a  logical  channel  for  a  new 

incoming  call  will  be  to  use  the  lowest  logical  channel 
in  the  READY  state  in  the  range  of  LIC  to  HIC  and  LTC  to 
HTC . 

Note  6:  In  order  to  minimize  the  risk  of  call  collision,  the  DTE 
search  algorithm  is  suggested  to  start  with  the  highest 
numbered  logical  channel  in  the  READY  state.  The  DTE 
could  start  with  the  two-way  logical  channel  or  one-way 
outgoing  logical  channel  ranges. 
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ANNEX  2 

(to  Recommendation  X. 25) 

PACKET  LEVEL  DTE/DCE  INTERFACE  STATE  DIAGRAMS 
Symbol  definition  of  the  state  diagrams 


Note  1:  Each  state  is  represented  by  an  ellipse  wherein  the 
state  name  and  number  are  indicated. 

Note  2:  Each  state  transition  is  represented  by  an  arrow.  The 
responsibility  for  the  transition  (DTE  or  DCS)  and  the 
packet  that  has  been  transferred  are  indicated  beside 
that  arrow. 


Order  definition  of  the  state  diagrams 


For  the  sake  of  clarity,  the  normal  procedure  at  the  interface  is 
described  in  a  number  of  small  state  diagrams.  In  order  to 
describe  the  normal  procedure  fully  it  is  necessary  to  allocate  a 
priority  to  the  different  figures  and  to  relate  a  higher  order 
diagram  with  a  lower  one.  This  has  been  done  by  the  following 
means:  • 

-  The  figures  are  arranged  in  order  of  priority  with  Figure 
A2.1/X.2S  (Restart)  having  the  highest  priority  and  subse¬ 
quent  figures  having  lower  priority.  Priority  means  that 
when  a  packet  belonging  to  a  higher  order  diagram  is 
transferred,  that  diagram  is  applicable  and  the  lower  order 
one  is  not. 

-  The  relation  with  a  state  in  a  lower  order  diagram  is  given 
by  including  that  state  inside  an  ellipse  in  the  higher 
order  diagram. 

'•> 
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tfotel:  State  pi  for  virtual  calls  or  state  dl  for  permanent  virtual 
circuits  and  datagram. 

Hote  2:  This  transition  may  take  place  after  timeout  T10. 

Figure  A2.1/X.25  .  Diagram  of  states  for  the  transfer  of  restart  packets. 
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figure  A2.2/X.25  -  Diagram  of  states  for  the  transfer  of  call  set-up  and 

call  clearing  packets  vithin  the  packet  level  ready  (rl) 


Non  l.~  Thi*  tramUkm  v*r  take  place  after  X12 


Figure  A2.3/X.25  -  Diagram  of  states  for  the  transfer  of  reset  packets 
within  the  data  transfer  (pit)  state 


ANNEX  3 

(to  Recommendation  X.25) 


ACTIONS  TAKEN  BY  THE  DCE  ON  RECEIPT  OF  PACKETS  IN  A  GIVEN  STATE 
OF  THE  PACKET  LEVEL  DTE/DCE  INTERFACE  AS  PERCEIVED  BY  THE  DCE 


TABLE  A3. 1 /X.25 
Special  cases 

The  number  following  the  •  is  the  diagnostic  code  (see  Annex  5). 


Packet  from  the  DTE 

Any  state 

Any  packet  with  packet 

DIAG 

length  <2  octets 

#38 

Any  packet  with  incorrect 

DIAG 

general  format  identifier 

#40 

Any  packet  with  unassigned 

DIAG 

logical  channel 

#36 

Any  packet  with  correct 

SEE  TABLE 

GFI  and  assigned 

A3. 2/X. 25 

logical  channel 

DIAG:  The  DCE  discards  the  received  packet  and,  for  networks 

which  implement  the  diagnostic  packet,  transmits  a  DIAG¬ 
NOSTIC  packet  to  the  DTE  containing  the  indicated  diagnos¬ 
tic  code. 

There  may  be  more  than  one  error  associated  with  a  packet. 
The  network  will  stop  normal  processing  of  a  packet  when 
an  error  is  encountered.  Thus  only  one  diagnostic  code  is 
indicated  in  the  DIAGNOSTIC  packet.  The  order  of  packet 
de-coding  and  checking  on  networks  is  not  standardized. 


Action  taken  by  the  DCE  on  receipt  of  packets  In  a  riven  state  of  the  packet  l»vel  DTE/DCE 
interface  as  perceived  by  the  DCE:  restart  procedure  for  assigned  logical  channels 


! 
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NORMAL: 


DISCARD: 


ERROR : 


Note  1: 


Note  2: 


NOTES  TO  TABLE  A3.2/X.25 


The  action  taken  by  the  DCE  follows  the  procedures  as 
defined  In  section  3.  If  a  RESTART  REQUEST  packet  or 
DTE  RESTART  CONFIRMATION  packet  received  in  state  r3 
exceeds  the  maximum  permitted  length,  the  DCE  will 
invoke  the  ERROR  procedure  with  diagnostic  139  and 
enter  state  r3.  If  a  RESTART  REQUEST  packet  received 
in  state  rl  exceeds  the  maximum  permitted  length,  the 
action  taken  by  the  DCE  is  for  further  study. 

The  DCE  discards  the  received  packet  and  takes  no  sub¬ 
sequent  action  as  a  direct  result  of  receiving  that 
packet. 

The  DCE  discards  the  received  packet  and  indicates  a 
restarting  by  transmitting  to  the  DTE  a  RESTART  INDICA¬ 
TION  packet,  with  the  cause  aLocal  procedure  error" 
(diagnostic  per  Table  A3.2/X.25).  If  connected  through 
the  virtual  call,  the  distant  DTE  is  also  informed  of 
the  restarting  by  a  CLEAR  INDICATION  packet,  with  the 
cause  "Remote  procedure  error"  (same  diagnostic).  In 
the  case  of  a  permanent  virtual  circuit,  the  distant 
DTE  will  be  informed  by  a  RESET  INDICATION  packet,  with 
the  cause  "Remote  procedure  error"  (same  diagnostic). 

If  a  RESTART  INDICATION  is  issued  as  a  result  of  an 
error  condition  in  state  r2,  the  DCE  should  eventually 
consider  the  DTE/OCE  interface  to  be  in  the  PACKET 
LEVEL  READY  state  (rl). 

There  may  be  more  than  one  error  associated  with  a 
packet.  The  network  will  stop  normal  processing  of  a 
packet  when  an  error  is  encountered.  Thus  only  one 
diagnostic  code  is  associated  with  an  ERROR  Indication 
by  the  DCE.  The  order  of  packet  de-coding  and  checking 
on  networks  is  not  standardized. 

pi  for  logical  channels  assigned  to  virtual  calls;  dl 
for  logical  channels  assigned  to  permanent  virtual  cir¬ 
cuits  and  datagrams. 


PACKETS  HAVINC  A  PACKET  TYPE  ERROR  ERROR  ERROR  SEE  TABLE  |ERROR  ERROR  DISCARD 

IDENTIFIER  WHICH  IS  SHORTER  (p7)  (pT)  <pT)  A3.’»/X.?5  |(pT)  (p7)  (p7) 

THAN  ONE  OCTET  OR  IS  NOT  #38  #38  #38  #38  #38 

SUPPORTED  BY  THE  DCe  *33  #33  #33  #33  #33 
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NORMAL: 

DISCARD: 

ERROR: 


Note  1: 

Note  2: 

Note  3: 

Note  4: 


NOTES  TO  TABLE  A3.3/X.25 


The  action  taken  by  the  DCE  follows  the  procedures  as 
defined  in  section  4.  If  the  packet  exceeds  the  max* 
imuro  permitted  length  the  DCE  will  invoke  the  ERROR 
procedure  with  diagnostic  139  and  enter  state  p7. 

The  DCE  discards  the  received  packet  and  takes  no  sub¬ 
sequent  action  as  a  direct  result  of  receiving  that 
packet. 

The  DCE  discards  the  received  packet  and  Indicates  a 
clearing  by  transmitting  to  the  DTE  a  CLEAR  INDICATION 
packet,  with  the  cause  "Local  procedure  error"  (diag¬ 
nostic  per  Table  A3.3/X.25).  If  connected  through  the 
virtual  call,  the  distant  DTE  is  also  informed  of  the 
clearing  by  a  CLEAR  INDICATION  packet,  with  the  cause 
"Remote  procedure  error"  (same  diagnostic). 

It  is  required  that  in  the  absence  of  an  appropriate 
DTE  response  to  a  CLEAR  INDICATION  packet  issued  as  a 
result  of  an  error  condition  in  state  p6,  the  DCE 
should  eventually  consider  the  DTE/DCE  interface  to  be 
in  the  READY  state  (pi). 

There  may  be  more  than  one  error  associated  with  a 
packet  (e.g.,  packet  too  long  and  transmitted  in  a 
wrong  state).  The  network  will  stop  processing  of  the 
packet  when  an  error  is  encountered.  Thus  only  one 
diagnostic  code  is  associated  with  an  ERROR  indication 
by  the  DCE.  The  order  of  packet  de-coding  and  checking 
on  networks  is  not  standard  1  zed . 

This  state  does  not  exist  in  the  case  of  an  outgoing 
one-way  logical  channel  (as  perceived  by  the  DTE). 

This  state  does  not  exist  in  the  case  of  an  incoming 
one-way  logical  channel  (as  perceived  by  the  DTE). 

(a)  In  the  case  of  an  incoming  one-way  logical  channel 
(as  perceived  by  the  DTE)  the  DCE  will  transmit  a 
CLEAR  INDICATION  with  the  cause  "Local  procedure 
error"  and  diagnostic  #34. 

(b)  The  DCE  will  transmit  a  CLEAR  INDICATION  if  the 
CALL  REQUEST  contains  an  improper  address  format  or 
facility  field;  call  progress  signals  and  diagnos¬ 
tic  codes  are  listed  below: 


\ 


MICROCOPY  R£  SOLUTION  TL  ST  CHART 

NAMONAl  MUM  An  <>l  'it AN| iAKI i\  !'».<  A 
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Error  Condition 

1.  Address  contains  a  non  BCD  digit 

2.  Prefix  digit  not  supported 

3.  National  address  smaller  than 

national  address  format  permits 

4.  National  address  larger  than 

national  address  format  permits 

5.  DNIC  less  than  four  digits 

6.  Facility  length  larger  than  63 

7.  No  combination  of  facilities 
could  equal  facility  length 

8.  Facility  length  larger  than 
remainder  of  packet 

9.  Facility  values  conflict  (e.g., 
a  particular  combination  not 
supported) 

10.  Facility  code  not  allowed 

11.  Facility  value  not  allowed 


Possible 

Cause 

Diagnostics 

Local  Procedure 

Er  ror 

#67, 6P 

IV 

a 

a 

a 

II 

a 

a 

a 

• 

a 

a 

a 

a 

a 

a 

a 

H 

a 

a 

#54 

a 

a 

a 

#84 

■ 

a 

a 

#38 

a 

a 

a 

•  86 

Inval  id 

Facility 

Request 

#65 

N 

a 

a 

#66 

(c)  The  DCE  will  transmit  a  CLEAR  INDICATION  If  the 

remote  DTE  makes  a  procedure  error,  either  for  one 
of  the  above  reasons  associated  with  its  call 
acceptance,  or  because  of  an  expired  timeout  (diag¬ 
nostic  #49). 

Mote  St  In  the  case  of  an  permanent  virtual  circuit,  the  DCE 
discards  the  received  packet  and  Indicates  a  reset  by 
transmitting  to  the  DTE  a  RESET  INDICATION  packet,  with 
the  cause  "Local  procedure  error”  (diagnostic  #35). 

The  distant  DTE  is  also  informed  of  the  reset  by  a 
RESET  INDICATION  packet,  with  the  cause  "Remote  pro¬ 
cedure  error"  (same  diagnostic). 

In  the  case  of  a  datagram  logical  channel,  the  DCE  dis¬ 
cards  the  received  packet  and  Indicates  a  reset  by 
transmitting  to  the  DTE  a  RESET  INDICATION  packet,  with 
the  cause  "Local  procedure  error". 

Note  fit  The  ERROR  procedure  will  be  invoked  by  the  DCE  if  the 
CALL  ACCEPTED  packet  contains  an  Improper  address  for¬ 
mat  or  facility  field.  Examples  are  similar  to  those 
in  Note  4  point  (b)  above. 


Note  7:  The  presence  of  the  Fast  Select  facility,  indicating 

restriction  on  response  in  an  INCOMING  CALL  packet 
prohibits  the  DTE  from  sending  a  CALL  ACCEPTED  packet. 
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NORMAL: 


DISCARD: 


ERROR: 


Note  1: 


Note  2: 


NOTES  TO  TABLE  A3.4/X.25 


The  action  taken  by  the  DCE  follows  the  procedures 
as  defined  in  sections  4  and  5.  If  the  packet  exceeds 
the  maximum  permitted  length,  the  DCE  will  Invoke  the 
ERROR  procedure  using  diagnostic  code  139  and  enter 
state  d3. 

The  DCE  discards  the  received  packet  and  takes 
no  subsequent  action  as  a  direct  result  of  receiving 
that  packet. 

The  DCE  discards  the  received  packet  and  indicates 
a  reset  by  transmitting  to  the  DTE  a  RESET  INDICATION 
packet,  with  the  cause  "Local  procedure  error" 
(diagnostic  per  Table  A3.4/X.2S).  For  virtual  calls  and 
permanent  virtual  circuits,  the  distant  DTE  is  also 
informed  of  the  reset  by  a  RESET  INDICATION  packet, 
with  the  cause  "Remote  procedure  error”  (same 
d iagnostic) . 

If  a  RESET  INDICATION  is  issued  as  a  result  of  an 
error  condition  in  state  d2  for  permanent  virtual 
circuits  and  datagram  logical  channels,  the  DCE 
should  eventually  consider  the  DTE/DCE  interface 
to  be  in  the  FLOW  CONTROL  READY  state  (dl)  In 
this  case,  the  action  to  be  taken  on  a  virtual 
call  is  for  further  study. 


There  may  be  more  than  one  error  associated  with  a 
packet  (e.g..  Invalid  P(S)  and  Invalid  P(R)).  The 
network  will  stop  processing  of  the  packet  when  an 
error  is  encountered.  Thus  only  one  diagnostic  code 
Is  associated  with  an  ERROR  Indication  by  the  DCE. 
The  order  of  packet  de-coding  and  checking  on 
networks  is  not  standardized. 

The  DCE  will  consider  the  receipt  of  a  DTE  INTERRUPT 
CONFIRMATION  packet  which  does  not  correspond  to  a 
yet  unconfirmed  DCE  INTERRUPT  packet  as  an  error 
and  will  reset  the  virtual  call  or  permanent  circuit 
(diagnostic  #43).  The  DCE  will  either  discard  or 
consider  as  an  error  a  DTE  INTERRUPT  packet  received 
before  a  previous  DTE  INTERRUPT  packet  has  been 
confirmed  (diagnostic  144). 

If  the  P(S)  or  P(R)  received  is  not  valid,  the  DCE 
will  Invoke  the  ERROR  procedure  with  diagnostics 
•1  and  12  respectively,  and  enter  state  d3. 
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ANNEX  4 

(to  Recommendation  X.25) 

PACKET  LEVEL  DCE  TINE-OUTS  AND  DTE  TIME-LIMITS 


DCE  tlm-out« 


Under  certain  circumstances  this  Recommendation  requires  the  DTE 
to  respond  to  a  packet  issued  from  the  DCE  within  a  stated  max¬ 
imum  time. 

Table  A4.1/X.2S  covers  these  circumstances  and  the  actions  that 
the  DCE  will  Initiate  upon  the  expiration  of  that  maximum  time. 


DTE  time-limits 


Under  certain  circumstances,  this  Recommendation  requires  the  DCE 
to  respond  to  a  packet  from  the  DTE  within  a  stated  maximum  time. 
Table  A4.2/X.25  gives  these  maximum  times.  The  actual  DCE 
response  times  should  be  well  within  the  specified  time-limits. 
The  rare  situation  where  a  time-limit  is  exceeded  should  only 
occur  when  there  is  a  fault  condition. 

To  facilitate  recovery  from  such  fault  conditions,  the  DTE  may 
incorporate  timers.  The  time-limits  given  in  Table  A4.2/X.25  are 
the  lower  limits  of  the  times  a  DTE  should  allow  for  proper 
operation.  A  time-limit  longer  than  the  values  shown  may  be 
used.  Suggestions  on  possible  DTE  actions  upon  expiration  of  the 
time-limits  are  given  in  Table  A4.2/X.2S. 

Mote:  A  DTE  may  use  a  timer  shorter  than  the  value  given  for  T21 
in  Table  A4.2/X.25.  This  may  be  appropriate  when  the  DTE 
knows  the  normal  response  time  of  the  called  DTE  to  an 
incoming  call.  In  this  case,  the  timer  should  account  for 
the  normal  maximum  response  time  of  the  called  DTE  and  the 
estimated  maximum  call  set-up  time. 


DCE  TIME-OUTS 
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Note  1 


Note  2 


Note  3 


Note  4 


NOTES  TO  TABLE  A4.1/X.25 


The  following  Notes  2,  3  and  4  describe  alternative  DCE 
actions  on  timer  expiration.  It  is  envisaged  that  all 
networks  will  eventually  conform  to  Table  A4.1/X.25, 
however  for  an  interim  period  the  following  procedures 
may  be  used. 

No  values  have  yet  been  assigned  to  the  time-out  t  and 
the  maximum  number  of  retries  n  applying  to  the  follow¬ 
ing  notes,  however  it  should  be  noted  that  some  Adminis¬ 
trations  may  use  the  combination  t-infinite,  n-zero 
(i.e.,  no  retries  and  no  recovery  action)  or  t-flnite, 
n-zero  (i.e.,  no  retries  with  recovery  action  on  timer 
expiration).  The  values  of  n  and  t  will  not  necessarily 
be  the  same  for  the  clear,  reset  and  restart  procedures. 

Alternatively,  the  DCE  will  retransmit  the  RESTART  INDI¬ 
CATION  at  regular  intervals  of  t  until  a  DTE  RESTART 
CONFIRMATION  is  received  or  a  restart  collision  occurs 
or  a  period  (n  +  1 ) t  elapses  since  the  first  transmis¬ 
sion  of  the  RESTART  INDICATION.  If  the  restart  pro¬ 
cedure  is  not  completed  within  the  time-out  period, 
appropriate  recovery  action  will  be  taken. 

Alternatively,  the  DCE  will  transmit  the  RESET  INDICA¬ 
TION  at  regular  intervals  of  t  until  a  DTE  RESET  CONFIR¬ 
MATION  is  received  or  a  reset  collision  occurs  or  a 
period  (n  +  l)t  elapses  since  the  first  transmission  of 
the  RESET  INDICATION.  If  the  reset  procedure  is  not 
completed  within  the  time-out  period  the  DCE  will 
either: 

l)  clear  the  virtual  call  with  an  indication  of  pro¬ 
cedure  error,  or 

il)  in  the  case  of  permanent  virtual  circuit  forward  a 
RESET  INDICATION  (remote  procedure  error)  to  the 
local  DTE  at  regular  intervals  t  until  a  DTE  RESET 
CONFIRMATION  is  received  or  a  reset  collision 
occurs. 

Alternatively,  the  DCE  will  retransmit  a  CLEAR  INDICA¬ 
TION  at  regular  intervals  of  t  until  a  DTE  CLEAR  CONFIR¬ 
MATION  is  received  or  a  clear  collision  occurs  or  a 
period  (n  +  l)t  elapses  since  the  first  retransmission 
of  the  CLEAR  INDICATION.  If  the  clear  procedure  is  not 
completed  within  the  time-out  period,  appropriate 
recovery  action  will  be  initiated.  The  nature  of  the 
recovery  action  is  for  further  study. 


DTE  TIME-LIMITS 
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Note  1:  After  unsuccessful  retries,  recovery  decisions  should  be  taken  at  higher  levels. 

Note  2:  After  unsuccessful  retries,  the  logical  channel  should  be  considered  out-cf-order.  Hie  restart  procedure 
should  only  be  invoked  for  recovery  if  reinitialization  of  all  logical  channels  is  acceptable. 
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ANNEX  5 

(to  Recommendation  X.25) 

COOING  OF  X. 25  NETWORK  GENERATED  DIAGNOSTIC  FIELDS  IN  CLEAR, 

RESET  AND  RESTART  INDICATION  AND  DIAGNOSTIC  PACKETS  (Notes  1,  2  and  3) 


Diaqnostics 

No  Additional  Information 

Invalid" F7sl - 

Invalid  P(R) 
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Decimal 
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2 

15 

Packet  type  invalid 

0 
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0 

1 
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0 
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0 

0 

1 

0 

1 

1 

1 

1 

47 
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For  INCOMING  CALL 
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for  CLEAR  INDICATION 
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for  RESET  INDICATION 

0 

0 

1 

1 

0 

0 

1 

1 

51 
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0 
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Invalid  called  address 

0 
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1 
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0 

0 

0 

0 

0 
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specific  diagnostic 
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• 

• 

information 

1 

1 

1 

1 

1 

1 

1 

1 

255 

Note  1:  Not  all  diagnostic  codes  need  apply  to  a  specific  net¬ 
work,  but  those  used  are  as  coded  in  the  table. 


Note  2:  A  given  diagnostic  need  not  apply  to  all  packet  types 

(i.e.,  RESET  INDICATION,  CLEAR  INDICATION,  RESTART  INDI¬ 
CATION  and  DIAGNOSTIC  packets) . 


Note  3;  The  first  diagnostic  in  each  grouping  is  a  generic  diag¬ 
nostic  and  can  be  used  in  place  of  the  more  specific 
diagnostics  within  the  grouping.  The  decimal  0  diagnos¬ 
tic  code  can  be  used  in  situations  where  no  additional 
information  is  available. 


EDITOR'S  NOTE:  A  CCITT  Transport  working  committee  is  expected 
to  identify  and  approve  LAPX  requirements  in 
September  1980 . 

TITLE  :  PROPOSED  DRAFT  RECOMMENDATION  S.h, 

NETWORK  INDEPENDENT;  BASIC  TRANSPORT  SERVICE  FOR  TELETEX 

1  The  CCITT  considering  that 

-  The  Teltex  Service  will  be.  introduced  in  different 
types  of  network,  i.e. 

i)  Circuit  Switched  Public  Data  Network  (CSDN) 

ii)  Packet  Switched  Public  Data  Network  (PSDN) 

iii)  General  Switched  Telephone  Network  (GSTN) 

-  There  is  a  need  for  international  interworking  between 
Teletex  terminals  connected  to  different  types  of  networks. 
Unanimously  declares  that:-  this  Recommendation  defines 
the  Network  Independent  Basic  Transport  Service  (NITS) 
applicable  Teletex  terminals  connected  to  the  above 
mentioned  types  of  network  in  terms  of  the 

-  Transport  Services  provided  to  the  higher  layer.  The 
Transport  Services  are  provided  by  the  transport  layer 
(layer  4)  in  association  with  the  underlying  services 
provided  by  the  supporting  layers  1-3 . 

-  Transport  layer  procedure  ( see  section  5 ) . 

2  TRANSPORT  SERVICE 

2 . 1  Objectives  of  Transport  Service 

The  purpose  of  the  transport  service  is  to  provide  two 
communicating  session  entities  within  Teletex  terminals 
with  f’-ansport  services,  i.e.  the  means  for  transparent 
and  reliable  end-to-end  transfer  of  data  between  them 
irrespective  of  the  parti cular  type  of  network  used. 

The  main  requirements  of  the  transport  service  to  be 
provided  by  a  transport  entity  to  the  local  transport 
user,  i.e.  the  session  entity,  are: 

i)  Network  Independence.  The  transport  service  shall 

be  homogeneous,  while  allowing  a  suitable  wide  variety 
of  underlying  communications  media,  protocols  and 
mechanisms . 

ii)  End- to  End  Significance .  The  transport  service  shall 
have  end-to-end  significance,  connecting  the  end  users 
irrespective  of  the  number  of  individual  communications 
links  used. 

iii)  Transparency.  The  transport  service  shall  be  octet 
transparent,  i.e.  not  restrict  the  content,  format 
or  coding  of  the  information  (data  or  control), 
received  from  or  delievered  to  the  transport  user. 


iv)  Error  Free  Delivery.  The  transport  service  shall 
assure  error-free  delivery.  Non-recoverable  errors 
are  to  be  visible  to  the  transport  service  user. 


V) 


Cost  Efficiency.  The  transport  service  shall  optimize 
the  use  of  the  available  communication  resources  to 
provide  the  performance  required  by  each  communicating 
transport  user  at  maximum  efficiency. 

2.2  GENERAL  STRUCTURE  OF  THE  TRANSPORT  SERVICE 

The  general  structure  of  the  transport  service  is  shown 
in  Fig.  2.1/s  — 


TRANSPORT  LAYER 
(LAYER  4) 


NETWORK  LAYER 

(LAYERS) 


LINK  LAYER 
(LAYER  2) 


PHYSICAL  LAYER 
( LAYER  I ) 


TO  ANO  FROM  TRANSPORT  USEJK  SESSION  LAYER) 


CALL  CONTROL  PHASE 


OAIA  TRANSFER  PHASE 


CALL  CONTROL  PHASE 
DATA  TRANSFER  PHASE 


PSON 


CSDN 


SSTN 


Figure  2.1/S  ...  Transport  Service  General  Structure 


Notes : 

1.  The  X.25  network  layer  procedure  is  introduced  to 
ease  inter-working  with  PSDN's. 

2.  The  establishing  of  the  network  connection  is 
performed  in  two  stage  selection,  first  using 
normal  telephone  procedures  and  second  using  X2S 
call  control  procedures. 

3.  For  terminals  connected  to  GSTN  accessing  PSDN,  the 
procedures  in  note  2  apply. 

4.  LAP  X  is  a  half-duplex  link  access  procedure,  based 
on  recommendation  X75  for  single  link  operation 

( See  section  3.2.2.). 

5.  The  lime  level  procedures  are  in  accordance  with 
X75  for  single  link  operation  (however  see  section 
3.2.2  and  3.3.2)  and  in  this  respect  Recommendation 
X75  (1980  version)  is  to  be  regarded  as  the  reference 
specification  of  this  protocol. 

6.  In  case  of  interworking  between  Teletex  Terminals 
connected  to  different  types  of  networks  (i.e. 

CSDN,  PSDN,  GSTN)  this  Transport  Layer  Procedure  is 
executed  peer-to-peer  between  the  communication 
Teletex  Terminals. 

7.  For  terminals  connected  to  CSDNs,  no  function  is 
needed  in  the  network  layer  in  the  data  transfer 
phase  as  indicated  in  fig.  2.1/S.  However,  in 
order  to  facilitate  interworking  with  PSDNs  a 
minimum  network  layer  is  introduced  (see  section 
3.3.3). 

8.  The  modem  may  also  be  integrated  within  the  terminal 
and  in  such  cases  recommendation  V24  need  not  apply 

( see  3.2.1). 

9.  For  autmatic  calling  and/or  answering  recommendation 
V.2S  may  be  applicable. 

3.  TRANSPORT  SERVICE  REALIZATION  FOR  DIFFERENT  TYPES  OF 

NETWOfeKS 


The  transport  layer  procedure  on  all  types  of  network  is 
defined  in  section  5.  The  network  dependent  control  pro¬ 
cedures  of  the  underlying  layers  are  described  in  the  fol¬ 
lowing  sections. 


3 . 1  Terminals  connected  to 
Data  Network 


rewa 


a  Packet  Switched  Public 


3.1.1  Physical  layer  DTE/DCE  interface  characteristics 
The  physical  layer  of  Recommendation  X.2S  applies. 
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3.1.2 


Link  Layer  Procedure 


The  link  layer  procedure  shall,  unless  otherwise 
specified  be  the  symmetrical  procedures  as  specified 
in  X2S  LAPB  and  compatible  with  Recommendation  X.75 
for  single  link  operation. 

3.1.3  Network  Laver  Procedure 

Recommendation  X25  Virtual  Call  procedures  apply. 
However  the  following  points  should  be  noted: 

1)  Qualifier  bit  in  Data  Packets  should  always 
be  set  to  zero. 

2)  Delivery  Confirmation  bit  in  all  packets  should 
be  set  to  zero. 

3)  The  Teletex  terminal  should  not  send  an  Interrupt 
Request  packet. 

4)  Normal  X2S  Reset  procedures  will  apply.  However 
for  CSDN/PSDN  interworking  X2S  reset  will  be 
mapped  to  link  level  disconnection  on  CSDN. 

5)  Transport  Control  Blocks  and  Transport  Data 
Blocks  shall  be  carried  in  a  complete  Data 
Packet  sequence. 

6)  The  Teletex  Terminal  should  not  send  a  DTE 
REJ  packet. 

7)  Terminals  using  this  transport  protocol  shall  use 

a  specific  protocol  identifier  within  Call  Request/ 
Incoming  Call  packets  for  the  Teletex  Service. 

This  identifier  is  represented  by  the  first  octet 
of  the  Call  User  Data  field  as  shown  below: 

bit  87654321 
octet  1  00000010 

In  the  case  of  CSDN/PSDN  interworking  the  func¬ 
tional  mapping  of  this  protocol  identifier  requires 
further  study. 

8)  Teletex  terminals  shall  not  use  the  Fast  Select 
facility. 


3.2 


Terminals  connected  to  the  General  Switched  Telephone 
Network 


3.2.1  Physical  layer  DTE/DCE  Interface  characteristics 

The  DTE/DCE  physical  interface  characteristics  defined 
as  the  physical  layer  element  shall  be  in  accordance 
ewith  existing  v  series  Recommendations.  The  physical 
layer  may  provide  for  half-duplex  or  full-duplex 
transmission  depending  on  the  modern  standard. 

Note:  The  GSTN  modern  standards  are  discussed  in 
SG  XVII.  Furthermore,  in  case  of  modem  integrated 
in  the  terminal  the  interface  may  only  be  functionally 
equivalent  to  v  series  Recommendations.  This  is  also 
for  further  consideration  of  SG  XVII. 

3*2.2  Link  Layer  Procedure 

Depending  on  the  service  provided  by  the  physical 
layer,  the  link  layer  procedures  over  a  single 
physical  circuit  between  two  terminals  have  to  cater 
for  half-duplex  or  full-duplex  transmission  facility 
to  provide  a  full-duplex  service  to  the  network 
layer.  For  full-duplex  physical  layer  service,  the 
link  layer  procedure  shall  conform  to  the  Link  Access 
Procedure  described  in  Rec  X75,  for  single  link 
operation.  For  addressing  assignments  and  the  system 
parameters  see  sections  3. 2. 2.1,  3. 2. 2. 2  respectively. 

For  half-duplex  physcial  layer  service  the  link  layer 

procedure  (LAPX)  will  apply.  LAPX  is  a  half-duplex 

Link  Access  Procedure,  based  on  recommendation  X75 

for  single  link  operation.  Some  elements  of  the  link 

layer  procedure  have  been  established  but  neet  to  1 

be  studied  further  under  Q. . .  These  elements  which 

have  already  been  proposed  are  appended  to  the  text  t 

of  the  question.  I 

3. 2. 2.1  Procedure  for  Addressing  j 

The  following  describes  the  application  of  the 
link  addressing  procedure  of  Rec.  X.75.  Link 
addresses  (A  and  B)  shall  be  assigned  dynamically 
or  on  a  per  call  basis  according  to  the  following 
rule: 

The  calling  terminal  shall  take  Address  A 

The  called  terminal  shall  take  Address  B  i 
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Commands  and  Responses  shall  be  transfered  as 
shown  below: 


CALLING 

Comands  (B) 

CALLED 

- »». 

TERMINAL 

Responses  (B) 

TERMINAL 

A 

Comeads  (A) 

B 

^ - 

Responses  (A) 

- ► 

A  and  B  addresses  are  coded  as  follows: 

Address  12345678 

A  11000000 

B  10000000 

Note:  The  termianl  will  discard  all  frames 
received  with  an  address  other  than  A  and  B 

3. 2. 2. 2  Systems  Parameters 

Timer,  T1 

Maximum  number  of  retransmission,  N2 
Maximum  number  of  bits  in  a  I  frame,  N1 
Maximum  number  of  outstanding  I  frames,  K 

The  above  system  parameters  are  to  be  specified  by 
the  Administration.*  however  the  possible  range  of 
values  which  may  be  attributed  to  each  presenter 
is  to  be  standardized  and  such  values  are  for 
further  study. 

3.2.3  Network  Layer  Procedure 

See  section  3.1.3.  In  addition  the  following  points 
apply 

1.  For  all  Calls  (GSTN  only,  GSTN  -  PSDN,  GSTN, 

PSDN  -  GSTN)  second  stage  addressing  will  apply 
using  X25  virtual  call  procedures.  The  calling 
terminal  should  include  the  called  address  and 
teh  calling  address  (see  note  2)  in  all  request 
packets.  The  format  of  the  called  address  shall 
conform  to:- 

a)  the  telephone  network  addressing  scheme  for 
GSTN  only  calls. 

BL 


b)  the  telephone  network  addressing  scheme  with 

an  X121  DNIC  for  GSTN  -  PSDN  -  GSTN  calls.  (see 
note  3) 

0  c)  the  X121  addressing  scheme  for  GSTN  -  PSDN  calls. 

0  Note  1;  For  other  cases  of  internetworking  the 
above  rule  shall  apply. 

Note  2;  In  the  case  of  GSTN  -  PSDN  calls  the  veri¬ 
fication  of  the  calling  address  by  the  network 
requires  further  study. 

The  format  of  the  calling  address  is  for  further  study. 


Note  3 :  The  feasibility  of  such  connections  is  for 
further  study. 


3.3  Terminal  connected  to  Circuit  Switched  Public  Data 
Network 


3.3.1  Physical  Layer  DTE/DCE  Interface  Characteristics 

The  DTE/DCE  physical  interface  characteristics  shall 
be  in  accordance  with  Recommendation  X.21,  or  as  an 
option,  X.22  for  multi-call  operation. 


3.3.2  Link  Layer  Procedure 

The  Link  Layer  Procedure  shall  be  used  during  the  data 
phase  of  Rec.  X.21  or  X.21  bis  for  data  interchange 
over  a  single  physical  circuit  between  two  terminals 
operating  in  user  classes  3-7  as  indicated  in  Rec.  X.l. 
The  Link  Layer  Procedures  shall  conform  to  the  level 
2  procedures  described  in  Rec.  X75  for  single  link 
operation. 

3. 3. 2.1  Procedure  for  Addressing 

The  following  describes  the  application  of  the 
Link  Addressing  Procedures  of  recommendation 
X75 .  Link  addresses  (A  and  B)  shall  be  assigned 
dynamically  on  a  per  call  basis  according  to 
the  following  rule: 


The  calling  terminal  shall  take  Address  A 
The  called  terminal  shall  take  Address  B 


Commands  and  Responses  shall  be  transferred 
as  shown  below: 


i  CALLING 

Commands  (B) 

TERMINAL 

Responses  (B) 

i 

1  A 

i 

Commands  (A) 

•< 

i 

i _ 

Responses  (A) 

_ 

07 

called 

TERMINAL 
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The  coding  addresses  A  and  B  are  chosen  below: 

Address  12345678 

A  11000000 

B  10000000 

Mote:  The  terminal  will  discard  all  frames 
received  with  an  address  other  than  A  and  B 

3. 2. 2. 2  System  parameters 

The  system  parameters  shall  have  the  following 
values : 

Timer  T1  =  6  sec  (for  average  I  frame  length  of 
518  octets) 

Maximum  number  of  retransmission  N2  =  8 
Maximum  number  of  outstanding  I  frames  k  =  7 
Maximum  number  of  bits  in  an  I  frame  N1  *  16512  bits 

The  actual  maximum  number  of  bits  in  an  I  frame 
is  a  terminal  design  parameter  which  may  depend 
upon  the  maximum  length  of  the  network  layer 
data  block.  The  lower  limit  for  Ml  to  be  imple¬ 
mented  by  Teletex  terminals  is  1152  bits. 

3.3.3  Metwork  Layer  Procedure 

a)  Call  Control  phase 

Call  control  procedures  conforms  to  Recommendation 
X.21,  or  as  an  option,  X.22  for  multi -call  oper¬ 
ation. 

b)  Data  transfer  phase 

A  minimal  network  layer  is  present  during  the 
data  transfer  phase  and  accommodated  through  the 
use  of  a  two  octet  Network  Block  Header.  The 
header  comprises  a  one  octet  length  indicator 
followed  by  a  network  block  type  code.  The  only 
network  block  currently  defined  is  a  Network  Data 
Block  as  shown  in  Fig .  3 . 1/S . 
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Fig  .  3.1/S  ...  Metwork  Data  Block. 
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1 )  Length  Indicator 

This  indicator  expresses  in  octets  the  length 
of  the  Network  Data  Block  header.  This  length 
does  not  include  octet  1. 

2)  The  More  Data  mark  (M)  is  used  to  preserve  the 
integrity  of  Transport  Layer  Control  and  Transport 
Data  Blocks .  When  M  is  set  to  1  it  indicates  that 
more  data  is  to  follow. 

3)  The  Qualifier  Bit  (Q)  is  introduced  to  provide  a 
functional  mapping  with  the  X25  Qualifier  bit 
for  CSDN/PSDN  interworking.  The  Q  bit  is  not 
used  for  the  Teletex  service  and  shall  be  set  to 
zero. 

INTERWORKING  BETW EEM  NETWORKS 

4.1  It  is  responsibility  of  Administrations*  to  decide 
in  which  network(s)  the  Teletex  service  is  to  be  provided. 

4.2  Three  possibilities  are  considered  below: 

i)  Teletex  Terminals  connected  to  a  Circuit  Switched 
Public  Data  Network  (CSDN) 

ii)  Teletex  Terminals  connected  to  a  Packet  Switched 
Public  Data  Network  (PSDN) 

iii)  Teletex  Terminals  connected  to  a  General  Switched 
Telephone  Network  (GSTN) 

Interworking  between  Teletex  terminals  connected  any 
network  must  be  possible. 

4.3  International  interworking  between  Teletex  Terminals 
shall  preferably  take  place  between  networks  of  the  same 
type  when  these  networks  are  provided  by  both  countries 
involved. 

4.4  In  the  case  of  international  interworking  between 
Teletex  terminals  connected  to  Public  Data  Networks  of 
different  types  Recommendation  X75  shall  apply. 

Note:  The  interworking  between  CSDNs  and  PSDNs  will 
require  a  gateway  function  between  the  two  networks.  Two 
specific  requirements  of  this  gateway  function  have 
been  identified: 

1.  For  an  interim  period  a  packet  level  Reset  in  a  PSDN 
will  be  mapped  to  a  link  level  disconnection  in  a  CSDN. 
Alternative  functional  mappings  are  for  further  study. 

2.  The  execution  of  necessary  supervisory  functions .  This 
aspect  requires  further  definition. 


TRANSPORT  LAYER  PROCEDURE 


5.1  Transport  Functions 

5.1.1  General  Overview 

The  transport  layer  will  perform  all  those  functions 
that  are  necessary  to  bridge  the  gap  between  the  services 
provided  by  the  Network  layer  and  the  services  needed 
by  the  Session  layer.  Therefore,  the  functions  per¬ 
formed  are  dependent  on  two  criteria:  the  services 
provided  by  the  underlying  Network  layer  and  the 
services  required  by  the  Session  layer. 

It  is  the  responsibility  of  the  transport  service 
user  to  select  a  given  quality  of  service  which  may 
imply  the  use  of  certain  transport  layer  functions 
such  as: 

-  Establishment  of  a  Transport  Connection 

.  transport  connection  identification 
.  transport  connection  multiplexing 

-  Data  Transfer 

.  sequence  control 
.  error  detection 
.  error  recovery 
.  segmenting  and  combination 
.  flow  control 
.  purge 

-  Termination  of  a  Transport  Connection 

Note:  Not  all  of  the  above  functions  will  be 
available  in  the  basic  transport  service  (see  5.1.2). 

5. 1.1.1  Transport  Service  Classes  and  Functions 

A  limited  set  of  functions  is  proposed  for  a 
basic  transport  service.  It  is  recognized  that 
as  more  general  studies  on  Transport  Service 
progress  more  sophisticated  functions  will  be 
introduced  within  the  Transport  Layer  and 
a  functional  negotiation  mechanism  will  be 
required  during  connection  establishment  to 
facilitate  interworking  between  different 
Transport  Service  implementations.  Further¬ 
more  it  seem  likely  that  Transport  Service 
functions  will  be  grouped  (for  ease  of  nego¬ 
tiation)  into  a  hierarchical  system  of  classes 
whereby  classes  occupying  superiro  positions  in 
the  hierarchy  implement  all  functions  of  lower 
classes  together  with  the  additional  functions 
identified  for  their  own  class. 
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It  is  therefore  proposed  that  during  transport 
connection  establishment  the  use  of  a  given 
transport  service  and/or  individual  transport 
service  functions  hould  be  negotiated  according 
to  the  following  rules: 

-  Calling  terminal  indicates  transport  service 
class  and/or  optional  functions  required. 

-  Called  terminal  indicates  the  transport  service 
class  and/or  optional  functions  that  it  is  wil¬ 
ling  to  support 

-  All  parameters  to  be  used  in  the  transport  con¬ 
nection  must  be  explicity  indicated  otherwise 
default  values  will  apply 

The  transport  service  class  for  the  basic  tele- 
tex  service  is  denoted  as  class  zero. 

5.1.2  The  basic  Transport  Service  for  Teletex 

Transport  Layer  functions  are  performed  by  Transport 
Layer  Protocol  Elements. 

Transport  protocol  information  and  control  units  are 
called  blocks  (see  Table  5.1/S..). 

The  Transport  Connection  Request  and  Transport  Connection 
Accept  blocks  are  used  to  indicate  the  protocol  class, 
and  optional  functions,  applying  to  a  transport  con¬ 
nection.  The  Connection  Clear  block  is  used  to  indicate 
the  reason  for  refusing  a  connection  establishment. 

Transport  Connection  Request  Block 
Transport  Connection  Accept  Block 
Transport  Connection  Clear  Block 
Transport  Data  Block 
Transport  Block  Reject  Block 

Table  5 . 1/S . .  Transport  Layer  Block  Types 

5. 1.2.1  Transport  Layer  Functions 

Basic  class  functions  and  associated  transport 
layer  protocol  elements,  i.e.  blocks,  include: 

-  Transport  Connection  Establishment,  Transport 
Connection  Identification,  optional  extended 
addressing  and  optional  transport  data  lbock 
size  negotiation  (Transport  Connection  Request 
Block,  Transport  Connection  Accept  Block  and 
Transport  Connection  Clear  Block); 
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-  Data  delimitation,  segmentation/combination  of 
arbitrarily  long  transport  service  data  units 
(TSDU) .  These  are  contained  within  Transport 
Data  blocks.  The  end  of  a  TSDU  is  indicated 
by  a  TSDU  End  Mark  in  the  last  data  block. 

-  Detection  and  indication  of  procedural  errors 
(Block  Reject  block). 

Other  characteristics  of  the  Buie  Transport 

Service  are: 

-  Maintenance  of  Transport  Service  Data  Unit 
integrity 

-  Overflow:  if  the  user  cannot  absorb  new  data 
and  if  the  appropriate  buffers  and  not  avai- 
lable,  flow  control  is  performed  at  network/ 
link  level  as  appropriate. 

-  Error:  Mo  mechanism  is  provided  within  the 
Transport  Service  to  facilitate  recovery  from 
detected  errors.  Where  such  errors  are  detected 
the  user  of  the  Transport  Service  should  be 
informed  in  order  that  appropriate  recovery 
action  may  be  taken. 

5.2  Description  of  connection  establishment  and  termination 
procedures 

The  transport  layer  connection  establishment  and  termination 
procedures  shall  also  be  used  for  negotiating  Transport 
Service  Class  and/or  optional  Transport  connection  functions. 

The  basic  transport  service  class  provides  means  to  esta¬ 
blish  a  transport  connection  using  a  Transport  Connection 
Request  block  and  a  Transport  Connection  Accept  block. 

This  exchange  provides: 

-  A  way  to  negotiate  options  - 

-  A  transport  connection  identification.  The  transport 
connection  is  identification  by  use  of  cross-reference. 

Each  end  of  the  connection  is  responsible  for  selecting 
a  suitable  Transport  Connection  Identifier. 

This  mechanism  provides  also  an  identification  of  the 
transport  connection  independent  of  any  network  con¬ 
nection  identification  and  therefore  provides  inde¬ 
pendence  from  the  life  of  the  network  connection.  The 
binary  value  0  should  not  be  used  as  an  identifier.  The 
use  of  such  references  for  reconnection  requires  further 
definition. 
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5.2.1  Transport  Connection  Request  Block 

The  calling  terminal  shall  indicate  a  transport  con¬ 
nection  request  by  transferring  a  Transport  Connection 
Request  block  to  the  remote  terminal.  The  Transport 
Connection  Request  block  includes  the  transport  func¬ 
tions  (e.g.  source  reference,  class,  and  optional 
functions )  for  negotiation  of  the  characteristics 
of  the  transport  connection  being  established. 

5.2.2  Transport  Connection  Accept  Block 

The  called  terminal  shall  indicate  is  acceptance 
of  the  transport  connection  by  transferring  a  Trans¬ 
port  Connection  Accept  block  to  the  remote  terminal . 
The  Transport  Connection  Accept  block  includes  the 
transport  parameters  applying  to  the  connection  and 
to  be  used  by  the  calling  terminal. 

5.2.3  Transport  Connection  Clear  Block 

If  a  transport  connection  cannot  be  established,  the 
called  terminal  shall  respond  to  the  Transport  Con¬ 
nection  Request  block  with  a  Transport  Connection 
Clear  block.  The  clearing  cause  shall  indicate  why 
the  connection  was  not  accepted. 

Note:  There  is  no  explicit  Transport  Connection 
Termination  procedure  for  the  basic  class.  For  the 
basic  class  the  lifetime  of  the  transport  connection 
is  directly  correlated  to  the  lifetime  of  the  sup¬ 
porting  network  connection. 

5.2.4  Transport  Connection  Collision 

If  the  calling  terminal  receives  a  Transport  Con¬ 
nection  Request  block  it  shall  transfer  a  Block 
Reject  Block  to  notify  the  called  terminal  of  the 
procedure  error. 

5.3  Description  of  Data  Transfer  Procedures 
5.3.1  General 

The  data  transfer  procedure  described  in  the  following 
subsections  applies  only  when  the  transport  layer  is 
in  the  data  transfer  phase,  that  is  after  completion 
of  Transport  Connection  establishment  and  prior  to 
a  clearing. 

Note:  When  a  connection  is  cleared.  Transport  Data 
blocks  may  be  discarded.  Hence  it  is  left  to  the 
Transport  Service  User  to  define  protocols  able  to 
cope  with  the  various  possible  situations  that  may 
occur. 
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5. 3. 1.1  Transport  Data  Block  Length 

The  standard  maximum  Transport  Data  Block  length 
is  128 . octets  including  the  data  block  header 
octets.  However,  the  Transport  Data  Block  length 
may  be  restricted  to  a  lower  value  when  the  Trans¬ 
port  Data  Block  is  concatenated  with  other  Trans¬ 
port  Data  Blocks  (see  5.5.3). 

Other  maximum  data  field  lengths  may  be  supported 
by  Teletex  Terminals  in  conjunction  with  an  optional 
Transport  Data  Block  Size  Negotiation  connection 
function  ( see  section  5 . 5 . 5 . 2  and  5 . 5 . 6 . 2 ) .  Optional 
maximum  data  field  lengths  shall  be  chosen  form 
the  following  list:  256,  512,  1024  and  2048 
octets. 

5. 3. 1.2  Transport  Service  Data  Unit  (TSDU)  End 

The  TSDU  End  mark  is  used  to  preserve  the  inte¬ 
grity  of  the  TSDU.  The  TSDU  End  mark  is  set 
to  binary  1  in  the  last  Transport  Data  Block 
carrying  information  related  to  a  certain  TSDU. 

In  case  of  a  TSDU  that  comprises  a  single  Trans¬ 
port  Data  Block  the  TSDU  End  mark  is  also  set 
to  1.  In.  all  other  cases  the  TSDU  End  mark  is 
set  to  zero. 

5.4  Treatment  of  Procedure  Errors 

At  any  time,  a  terminal  may  send  a  Transport  Block  Reject 
Block  to  report  to  the  remote  terminal  the  receipt  a 
block  which  is  invalid  or  not  implemented.  No  confirmation 
is  required  to  be  issued  by  the  terminal  following  the 
receipt  of  a  Transport  Block  Reject  Block.  A  terminal 
receibing  a  Transport  Block  Reject  Block  shall  take 
appropriate  recovery  action. 

5.5  Formats 


5.5.1  General 

All  Transport  Protocol  Information  Units  are  called 
Blocks .  All  blocks  contain  a  integral  number  of 
octets. 

Bits  of  an  octet  are  numbered  8  to  1  where  bit  1  is 
the  low  order  bit  and  is  transmitted  first.  Octets 
of  a  block  are  consecutively  numbered  starting  form 
1  and  are  transmitted  in  this  order. 

Data  blocks  are  used  to  transfer  Transport  Service 
Data  units  (TSDU)  transparently  whilst  maintaining 
the  structure  of  the  latter  by  means  of  TSDU  End 
mark. 
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Control  blocks  are  used  to  control  the  transport 
protocol  functions ,  including  optional  functions. 

A  parameter  field  is  present  in  all  control  blocks 
within  the  basic  transport  service  to  indicate  optional 
functions . 

The  parameter  field  contains  one  or  more  parameter 
elements.  The  first  octet  of  each  parameter  element 
contains  a  parameter  code  to  indicate  the  functions ( s ) 
requested. 

The  general  coding  structure  is  shown  in  Figure  5.1/S.. 


3  1 


parameter  code 

parameter 

length  indicator 

2  2 

parameter  value 

a 

Figure  *5 . 1/S . .  Parameter  Element  Coding  Structure 

The  parameter  code  field  is  binary  coded  and,  without 
extension,  provides  for  a  maximum  of  255  parameter. 

Parameter  code  11111111  is  reserved  for  extension  of 
the  parameter  code.  The  extension  mechanism  is  for 
further  study. 

Octet  2  indicates  the  length,  in  octets,  of  the  para¬ 
meter  value  field.  The  parameter  field  length  is 
binary  coded  and  bit  1  is  the  low  order  bit  of  this 
indicator . 

Octet  3  and  subseuqent  octets  contain  the  value  of  the 
parameter  identified  in  the  parameter  code  field. 

The  coding  of  the  parameter  value  field  is  dependent 
on  the  function  being  requested. 

5.5.2  Structure  of  Transparent  Control  and  Transparent 
Data  Blocks  ' ” 


Bits 

3  1 

Length 

indicator 

Block 

type 

Functional  Code 
Field  (Fixed 

Format) 

Parameter  or  Data 
Field  (Variable 
Format) 

Fie.  5.2/S..  General  Slock  Structure 
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Figure  5.2/S.,  illustrates  the  general  structure  of 
transport  layer  blocks .  A  summary  of  transport  layer 
blocks  is  given  in  Figure  5.3/S.. 


5. 5. 2.1  Length  Indicator  Field  (LI) 

Octet  1  contains  the  length  indicator  ( LI ) .  The 
value  of  this  indicator  is  a  binary  number  that 
represents  the  length  on  octets  of  the  Control 
block  (including  parameters)  and  the  header  length 
in  octets  of  Data  blocks  (excluding  any  subsequent 
user  information).  In  both  cases  this  length  does 
not  include  octet  1. 

The  basic  LI  consists  of  a  single  octet  with  a 
maximum  value  of  254  in  decimal  (i.e.,  a  binary 
value  of  11111110).  The  use  of  the  binary 
value  11111111  for  extension  purposes  is 
for  further  study. 

5.5.2.2  Block  Type  Field 

Octet  2  contains  the  block  type  code.  Bits  1  to 
4  of  octet  2  are  set  to  0  for  all  transport 
layer  blocks  currently  defined.  It  is  for  further 
study  to  determine  whether  or  not  bits  1  to  4 
are  required  for  future  extension  to  the  range 
of  transport  layer  blocks  currently  defined  or 
are  used  for  other  functions. 

5. 5. 2. 3  Functional  Code  Field 

Octet  3  and  subsequent  octets  contain  functional 
codes  in  a  fixed  format  as  per  the  block  type 
(see  Figure  5.3/S.). 

5. 5. 2. 4  Parameter  or  Data  Field 

A  parameter  field  or  a  data  field  may  optionally 
follow  the  functional  code  field. 

5.5.3  Concatenation 

Concatenation  of  Transport  Control  and/or  Transport 
Data  Blocks  is  not  applicable  to  the  basic  class. 
However  where  concatenation  is  used  in  the  future, 
the  arrangement  shown  in  figure  5.4/S.,  would  apply. 
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J 

Transport  Control  Block 

Transport  Control  Block 

• 

Transport  Data  Block  Header 

< 

Transport  User  Data 

• 

< 

HDLC  Frame  Check  Sequence 

me  Flag 

Network  Level 


! 

Transport  Level 


Session  Level  and  Above 

Link  Level 


I 

I 


Fig.  5.4/S..  Information  Field  structure  of  HDLC  I  -  frame  (Example) 


Note:  This  figure  does  not  imply  that  a  transport 
data  or  control  block  will  fit  within  a  single  network 
data  block. 

5.5.5  Transport  Connection  Request  block  format 


Figure  5.5/S.,  illustrates  the  format  of  the  Transport 
Connection  Request  block. 


9-/ « 


Bits  87654321 


Octets  l 
2 

3 

4 

5 

6 
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Fig.  5.5/S..  -  Transport  Connection  Request  Block  (TCR) 

1)  Block  Type:  TCR 

2)  Transport  service  Extension  Field:  Octet  7  is  reserved 
for  any  future  extension  such  as  providing  for  a  range 
of  Transport  Service  Classes.  In  the  basic  Transport 
service  this  octet  shall  be  set  to  zero. 

3)  The  Parameter  field  is  present  only  when  the  terminal  is 
requesting  an  optional  Transport  connection  function. 

5. 5. 5.1  Parameters  For  Extended  Addressing 

Separate  parameters  are  provided  for  the  indication 
of  called  and  calling  Extension  Addresses.  The 
coding  of  these  parameters  is  shown  below: - 


5. 5. 5. 2  Parameter  For  Transport  Data  Block 
Size  Negotiation 

This  parameter  defines  the  proposed  maximum 
Transport  Data  Block  Size  (in  octets  including 
the  Transport  Data  Block  Header)  to  be  used 
over  the  requested  transport  connection.  The 
coding  of  this  parameter  is  shown  below: - 


Bits 

Octet  1 
2 
3 


8  765  4321 


110 


0  0 


0  0  0  0 


0  0  0  1 


0  0  0  0  X  X  X  X 


Parameter  Type  Code 
Parameter  Length  Indicator 
Transport  Data  Block  Size 


X  X  X  X  *  1001  -  2048  octets 

1010  -  1024 
1001  -  512 

1000  -  256 

0111  -  128 


5.5.6  Transport  Connection  Accept  Block  Format 

Figure  5 . 6/S . .  illustrates  the  format  of  the  Transport 
Connection -Accept  Block. 


Bits 

87654321 

Octet  I 

Length  (Octets) 

2 

H 

O 

O 

o 

o 

o 

r-l 

H 

3 

Destination 

4 

Reference 

5 

Source 

6 

Reference 

7 

0000000  0^ 

**  Parameters  (optional)  J  1 

Figure  5.6./S..  -  Transport  Connection  Accept  Block  (TCA). 

1)  Block  Type:  TCA 

2)  Transport  Service  Extension  Field:  Octet  7  is  reserved 
for  any  future  extension  such  as  providing  for  a  range 
of  Transport  Service  Classes.  In  the  basic  Teletex  ser¬ 
vice  this  octet  shall  be  set  to  zero  irrespective  of  the 
setting  in  the  Transport  Connection  Request  Block. 

3)  The  Parameter  Field  is  present  only  when  the  terminal  is 
requesting  an  optional  Transport  Connection  function. 


5. 5. 6.1  Parameters  For  Extended  Addressing 


See  section  5. 5. 5.1. 

5. 5. 6. 2  Parameter  For  Transport  Data  Block 
Size  Negotiation 

See  section  5. 5. 5. 2.  The  parameter  value  shall 
be  equal  to  or  less  than  the  value  specified  in 
the  Transport  Connection  Request  Block. 


5.5.7  Transport  Connection  Clear  Block  Format 


Octet 


Figure  5 . 7/S . .  illustrates  the  format  of  the  Transport 
Connection  Clear  Block. 


Bits 

8  7  6  5  4  3  2  1 
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o 

r4 
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4 

Reference 
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Source 

6 
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7 

2) 

Clearing  Cause 
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Figure  5.7/S..  -  Transport  Connection  Clear  Block  (TCC) 
1)  Block  Type:  TCC 


2 )  Clearing  Cause : 

0  -  Reason  not  specified 

1  -  Terminal  occupied 

2  -  Terminal  out  of  order 

3  -  Address  unknown 


Bit 


8  7 
0  0 
0  0 
0  0 
0  0 


6  5 
0  0 
0  0 
0  0 
0  0 


4  3 
0  0 
0  0 
0  0 
0  0 


2  1 
0  0 
0  1 
1  0 
1  1 


5. 5. 7.1  Parameter  For  Additional  Clearing 
Information 


This  parameter  is  provided  to  allow  additional 
informating  relating  to  the  clearing  of  the  con¬ 
nection.  The  coding  of  this  parameter  is  given 
below: - 


S-2-J 


Octet 


Bits  87654321  Parameter 

Code 


1  1  1 
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5.S.8  TrM«BQrt  Block  Reject  Block  Format 

Figure  5.8/S.,  illustrates  the  format  of  the  Block 
Reject  block. 


Bits  87654321 
Octet  1  Length  (octets) 

2  01110000 

3  Destination 

4  Reference 

5  Reject  Cause 
Parameter  Field 

Figure  5.8/S...  -  Transport  Block  Reject  block  (BRB) 

1)  Block  Type:  TBR 

2)  Reject  cause: 


0 

1 

2 

3 


Reason  not  specified 
Function  not  implemented 
Invalid  block 
Invalid  parameter 


Bit  8  7 

0  o 
0  0 
0  0 
0  0 


6  5  4 

0  0  0 

0  0  0 

0  0  0 

0  0  0 


3  2  1 
0  0  0 
0  0  1 
0  10 
Oil 


5. 5. 8.1  Rejected  Block  Parameter  (mandatory) 


This  parameter  is  used  to  indicate  the  bit 
pattern  of  the  rejected  block  up  to  and  in¬ 
cluding  the  octet  which  caused  the  rejection. 
Only  the  first  detected  procedural  error  or 
parameter,  which  cannot  be  acted  upon,  shall 
be  indicated  by  this  method.  The  coding  of 
this  paramter  is  given  below: - 


Bits  8  7  6  5  4  3  2  1 


Octet 
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I  1  1  0  0  0  0  0 


Parameter  Length  Indicator 
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5.5.9  Transport  Data  Block 


Figure  5.9/S...  illustrates  the  format  of  the  Transport 
Data  Block 

Bits  87654321 


Octet  1 

Length  (octets) 

2 

1 

1  1  1  0  0  0  01* 

3  2> 

TSDU 

0  0  0  0  0  0  0 

END 

4 

DATA 

n 

Figure  5.9/S...  -  Transport  Data  Block  (TD) 

1)  Block  Type:  TDT 

2)  TSDU  End:  indicates  the  end  of  TSDU  when  set  to  one. 
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1.1  Scope 


1.1.1  Recommendation  F.x  Lays  down  the  operational 
provisions  for  the  automatic  international  Teletex 
service.  On  the  technical  side,  Recommendation  S.c 
specifies  the  requirements  for  international  compati¬ 
bility  between  Teletex  terminals  and  Recommendations 
S.f  defines  the  character  repertoire  and  coded  char¬ 
acter  sets  for  the  international  Teletex  service.* 

1.1.2  Network-dependent  communication  procedures  for 
call  establishment  and  termination  are  defined  in 
Recommendation  S.c. 

1.1.3  This  Recommendation  defines  the  end-to-end  pro¬ 
cedures  to  be  used  within  the  Teletex  service. 

1.1.4  Specifically,  this  Recommendation  concerns  the 
end-to-end  control  procedures  that  are  network- inde¬ 
pendent.  The  network-dependent  procedures  forming  a 
network- independent  transport  service  are  specified  in 
Recommendations  S . .  . 

1.1.5  The  procedure  described  in  this  recommendation 
should  also  be  used  between  a  Teletex  and  the  Teletex/ 
Telex  conversion  facility. 

1.1.6  Interworking  between  Teletex  and  services  other 
than  telex  is  for  further  study. 

1.1.7  This  Recommendation  assumes  that  the  terminal 
initiating  a  call  is  the  terminal  regarded  as  responsible 
for  the  call  charges  and  that  it  retains  full  control  of 
the  call. 

1.1.8  The  provisions  of  the  recommendation  are  to  be 
regarded  as  a  first  stage  in  the  establishment  of  a 
Teletex  service  in  accordance  with  recommendations 
F.x,  S.c,  S.f,  and  S.h,  as  defined  in  1980.  Enhance¬ 
ments  and  additions  to  these  recommendations  must 
ensure  compatibility  with  establishment  services. 

1.2  Fundamental  principles 

1.2.1  The  relationship  between  the  Teletex  control  pro¬ 
cedures  and  the  transport  service  shall  respect  the 
following  principle.  The  higher  level  procedures  require 
the  transport  service  to  preserve  the  structure  of  blocks, 
which  may  be  of  arbitary  size,  given  to  it  by  the  session 
level  for  transmission.  Only  one  session  command  or  re¬ 
sponse  is  allowed  in  this  block.  Only  one  document  com¬ 
mand  or  response  is  allowed  in  a  CSUI  or  RSU1  field. 

*  For  draft  Recommendations  F.x,  S.c  and  S.f,  see  COM  VIII- 
No.  179,  182  and  183  respectively. 


1.2.2  The  sender  is  responsible  for  the  delivery  of 
the  information  in  his  Teletex  document  to  the  recip¬ 
ient's  store.  This  may  include  linking  and  other 
relevant  information. 

1.3  Definitions 


1.3.1  Terms  and  their  definitions  are  listed  in  Annex 
A.  Where  appropriate  each  definition  mentions  the 
Layer  to  which  it  refers. 

1.3.2  Some  of  the  terms  used  in  this  Recommendation 
have  been  defined  in  ways  that  may  differ  from  the 
meanings  of  similar  terms  in  other  Recommendations. 

2  FUNCTIONS  OF  PROCEDURES 

2.1  General 

2.1.1  The  broad  functional  categories  provided  to 
implement  the  Teletex  service  control  procedures  are 
listed  in  Tables  1  and  2/S.d. 


Command  i 

Response 

Abbreviation 

Reference 

Session 

establishment  and  clearing 

Command  session  start 

CSS 

3.2.1 

Response  session  start  positive 

RSSP 

3.2.2 

Response  session  start  negative 

RSSN 

3.2.3 

Command  session  end 

CSE 

3.2.4 

Response  session  end  positive 

RSEP 

3.2  5 

Command  session  abort 

CSA 

3.2.6 

Response  session  abort  positive 

RSAP 

3.2.7 

Informat 

ion  transfer 

Command  session  user 

CSUI 

3.2.8 

information 

Response  session  user  information 

RSUI 

3.2.9 

Session 

management 

Command  session  change 

CSCC 

3. 2. If 

control 

Response  session  change 

RSCCP 

3.2.11 

control  positive 

Table  1/S.d  -  Session  commands  and  responses 


Command 

Response 

Abbreviation 

Reference 

Document 

control 

Command  document  start 

CDS* 

3.4.1 

Response  document  general  reject 

3.4.2 

Command  document 
continue 

CDC* 

3.4.3 

Command  document 

CDCL 

3.4.4 

capability  list 

Response  document  capability  list 
list  positive 

RDCLP 

3.4.S 

Command  document  end 

CDE** 

3.4.6 

Response  document  end  positive 

RDEP 

3.4.7 

Command  document 

CDD 

3.4.8 

discard 

Response  document  discard 
positive 

RDDF 

3.4.9 

Command  document 

CDR 

3.4.10 

resynchronize 

Response  document 
resynchronous  positive 

RDRF 

3.4.11  1 

i 

Information  transfer 

Command  document  user 
information 

CDUI 

3.4.12 

Error  re< 

:overy 

Response  document  general  reject 

RDGR 

3.4.2 

Command  document  page 
boundary 

CDFB 

3.4.13 

Response  document  page  boundary 
positive 

RDFBF 

3.4.14 

i 

Response  document  page  boundary 
negative 

RDFBN 

3.4.15 

*  RDGR  is  used  as  a  negative  response  to  this  command.  A  specific 
negative  response  is  not  required. 


**  The  negative  response  to  this  command  is  RDFBN 

Table  2/S.d  -  Document  commands  and  responses 
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2:1.2  The  procedural  elements  have  also  been  listed 
in  the  appropriate  categories  since  the  definitions  of 
the  elements  together  with  their  associated  rules 
completely  specify  the  functions  of  the  procedures. 

2*2  Background  information 

This  section  is  given  as  an  aid  for  the  understanding  of 
the  procedures.  The  exact  definition  of  the  control 
procedures  are  given  in  subsequent  sections  of  this  re¬ 
commendation. 


2.2.1  Exchange  of  service  identification 

Two  terminals  when  connected  by  a  transport  service 
will,  at  session  establishment,  need  to  exchange  in¬ 
formation  identifying  the  CCITT  regulated  service  that 
they  intend  to  use  and  thus  invoke  the  relevant  service 
facilities  and  the  associated  protocol  e.g.  the  Teletex 
service  and  its  protocol.  The  use  of  service  identi¬ 
fication  for  other  services  is  for  further  study. 

2.2.2  Negotiation  of  Optional  Capability 

Two  methods  are  provided.  The  first  is  used  at  session 
i initiation,  to  exchange  a  limited  set  of  capabilities. 
The  second  method  may  be  needed  when  required,  after 
session  innitiation,  to  indicate  the  sender's  require¬ 
ments  for  extended  capabilities. 

2.2.3  Negotiation  of  storage  requirements 

Storage  availability  can  be  indicated  in  the  following 
ways. 

1.  When  a  call  is  established  it  is  implicity  assumed 
that  there  is  adequate  receive  memory  for  the  call. 
Exceptionally  a  receiver  memory  overflow  condition  may 
occur.  The  continued  sending  of  the  document  from  the 
source  will  be  stopped  by  the  sink.  The  recovery  mech¬ 
anism  shall  indicate  the  reason  for  stopping  the  trans¬ 
mission. 

2.  The  provision  is  also  made  in  the  procedure  for  a 
mandatory  indication  that  the  ability  of  the  receiving 
terminal  to  accept  traffic  is  jeopardized. 

3.  The  contact  procedure  also  provides  the  possibility 
to  investigate  the  storage  availability  at  the  receiving 
terminal  prior  to  the  transmission  of  a  document.  The 
use  of  this  possibility  is  for  further  study  within  the 
SAI . 


ELEMENTS  OF  PROCEDURE 


3 . 1  General 


3.1.1  This  section  contains  elements  of  procedure  and 
rules  of  use  that,  when  combined,  define  the  Teletex 
procedure. 

3.1.2  Definitions  applying  to  the  elements  of  proce¬ 
dure  may  be  found  in  Annexes  A  and  S. 

3.1.3  Annexes  C  and  D  describe  the  Two-way  simultaneous 
(TWS)  mode  of  session  operation  and  the  session  sus¬ 
pension  function,  which  are  not  applicable  to  the  basic 
Teletex  service. 

3 .2  Session  commands,  responses  and  parameters 

(For  a  summary  of  session  commands  and  responses,  see 
Table  1/S.d.) 

3.2.1  Command  session  start  (CSS) 

3. 3. 2. 2  The  CSS  initiates  entry  into  a  session. 

3 . 2 . 1 . 2  Command  parameters  are : - 

a)  Service  identifier.  This  mandatory  parameter 
identifies  the  service  (e.g.  Teletex,  facsimile) 
that  the  sender  of  this  command  intends  to  use. 

b)  Terminal  identifier.  This  mandatory  parameter 
identifies  the  calling  terminal  in  accordance  with 
the  terminal  identification  specified  in  Recom¬ 
mendation  F.X. 

c)  Date  and  time.  This  mandatory  parameter  gives 
date  and  time  information  as  specified  in  Reccom- 
dataion  F.x. 

d)  Additional  session  reference  number.  This 
number  may  be  used  in  addition  to  the  basic 
session  reference  (called  terminal's  identifier, 
calling  terminal's  identifier,  date  and  time)  to 
identify  uniquely  the  session.  If  the  additional 
session  reference  number  is  not  used  parameter 
shall  not  be  included. 

e)  Non-basic  terminal  capabilities  -  these  para¬ 
meters  indicate  which  non-basic  terminal  capabili¬ 
ties  are  available  as  receiving  capabilities  of  the 
sender  of  this  command. 
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These  parameters  are  mandatory  if  the  terminal 
is  capable  of  any  of  the  specific  functions  listed 
below,  absence  of  the  parameter  indicates  that 
the  specific  function  is  not  available. 


Parameter 

Function 

i) 

Control  character  sets 

Reverse  line  feed 

ii) 

Page  formats 

A4  printable  area  (verticc 
and  horizontal  orientation) 

iii) 

Miscellaneous  terminal 

Character  spacing  of  2.12  mm 

capabilities 

(12  characters  per  2S.4  mm i. 
Character  spacing  of  1.69mm 
(IS  characters  per  25.4  ms.  . 
Line  feed  parameter  value 
of  one  spacing  of  3.175  mm. 
Line  feed  parameter  value 
of  one  spacing  of  0.5,  l.C 
1.5  and  2  spacings  of  5  mm. 

Note:  The  definitions  of  these  presentation  cap¬ 
abilities  may  be  found  in  Recommendation  S.c. 
Future  extension  and  private-use  capabilities  are 
to  be  accommodated  in  CDCL. 

f)  Non-basic  session  capabilities.  If  used,  this 
non-mandatory  parameter  indicates  which  non-basic 
session  capabilities  are  available  as  receiving 
capabilities  of  the  sender  of  this  command. 

Note:  Examples  of  the  uses  for  this  parameter 
are  session  suspension  (see  Annex  D),  two-way 
simultaneous  operation  (see  Annex  C)  and  negoti¬ 
ation  of  the  window  size  for  checkpointing  (see 
section  4.3 ) . 

g)  Private  use  parameters.  These  parameters  are 
not  mandatory.  Their  definition  and  use  are  not 
standardized. 

3.2.2  Response  session  start  positive (RSSP) 

3. 2. 2.1  The  RSSP  shall  be  used  to  acknowledge 
entry  into  a  session.  It  indicates  that  the  CSS 
command  has  been  understood  and  is  in  a  correct 
format. 

3. 2. 2. 2  Response  parameters  are:- 

a)  Service  identifier.  This  mandatory  parameter 
identifies  the  service  (e.g.  Teletex,  facsimile 
that  the  sender  of  this  response  intends  to  use. 


Note:  For  the  basic  Teletex  service  the  service 
identifiers  in  RSSP  and  CSS  must  be  identical. 

b)  Terminal  identifier.  This  mandatory  parameter 
provides  the  terminal  identification  of  the  sender 
of  the  RSSP  in  accordance  with  the  terminal  iden¬ 
tification  specified  in  Recommendation  F.x. 

c)  Date  and  time.  This  mandatory  parameter  must 
be  identical  to  the  corresponding  parameter  in  the 
CSS.  It  is  used  in  conjunction  with  the  terminal 
identifications  of  both  terminals  in  a  session  as 
a  reference  to  that  session. 

d)  Additional  session  reference  number.  If  used 
in  the  CSS  and  if  used  by  the  receiver  of  CSS,  this 
parameter  shall  have  the  same  value  as  in  the  CSS. 

If  it  is  not  used  by  the  receiver  of  CSS  it  shall 
not  appear  in  the  RSSP. 

e)  Non-basic  terminal  capabilities  (i.e.  those 
available  as  receiving  capabilities  of  the  sender 
of  the  RSSP)  -  the  same  conditions  apply  as  for 
3. 2. 1.2  e  above. 

f)  Non-basic  session  capabilities  -  3. 2. 1.2  f  above. 

g)  Private  use  parameters  -  3. 2. 1.2  g  above. 

3.2.3  Response'  session  start  negative (RSSN) 

3 . 2 . 3 . 1  The  negative  response  indicates  that  the 
session  was  not  entered  by  the  receiver  of  the 
CSS.  It  is  not  mandatory  to  indicate  the  reasons 
for  rejection.  A  non-mandatory  private  use  para¬ 
meter  may  be  used  with  this  response. 

Note:  Reasons  to  be  identified  and  coded-  for 
further  study. 

3.2.4  Command  session  end  (CSE) 

3. 2. 4.1  The  CSE  is  used  for  normal  (or  error- free) 
termination  of  a  session. 

Note:  A  parameter  is  reserved  to  indicate  whether 
the  transport  connection  is  to  be  cleared.  Absence 
of  this  parameter  will  cause  the  transport  connection 
to  be  cleared. 


3.2.5  Response  session  and  positive  (RSEP) 

3. 2. 5.1  The  RSEP  indicates  to  the  calling  terminal 
that  the  called  terminal  can  enter  the  idle  state 
in  an  orderly  manner. 


3.2.6  Command  session  abort  (CSA) 

3. 2. 1.6.1  The  CSA  may  be  used  at  any  time  by 
either  terminal  to  terminate  a  session,  whenever 
a  condition  is  detected  indicating  that  the 
session  cannot  be  continued  successfully. 

3. 2. 1.6. 2  One  of  the  following  reasons  for 
the  abnormal  termination  of  the  session  must 
be  given  as  a  CSA  parameter 

a)  local  terminal  error; 

b)  unrecoverable  procedural  error; 

c)  reason  not  defined. 

Note:  One  value  is  reserved  to  indicate 
whether  the  transport  connection  is  to 
be  cleared. 

3.2.7  Response  session  abort  positive  ( RSAP ) 

3. 2. 7.1  The  RSAP  response  indicates  to  the  sender 
of  a  CSA  command  (either  the  source  or  the  sink 
terminal)  that  the  receiver  of  CSA  has  entered  the 
idle  state  in  an  orderly  manner. 

3.2.8  Command  session  user  information  ( CSUI ) 

3. 2. 8.1  The  CSUI  is  used  to  indicate  to  the  re¬ 
ceiver  that  the  associated  information  field  of 
this  command  conveys  commands,  parameters  and 
information  for  the  document  procedures . 

3. 2. 8. 2  CSUI  does  not  call  for  a  response.  There 
is  no  relationship  between  this  command  and  the 
response  RSUI. 

• 

3.2.9  Response  session  user  information  (RSUI) 

3. 2. 9.1  The  RSUI  is  used  to  indicate  to  the  re¬ 
ceiver  of  this  response  (source)  that  the  associated 
information  field  conveys  responses  and  parameters 
for  the  document  procedures.  A  non-mandatory 
parameter  "request  session  function"  may  be  used 
with  this  response. 
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3. 2. 9. 2  This  RSUI  response  is  not  related  to  any 
CSUI  command. 

3.2.10  Command  session  change  control  (CSCC) 

3.2.10.1  In  two-way  alternate  (TWA)  mode  CSCC 
changes  the  source/sink  relationship  between  the 
two  terminals . 

Note:  A  signal  for  Request  Transmit  is  available 
in  some  responses  (see  coding  scheme).  It  may  be 
used  to  indicate  that  a  terminal  sending  this 
signal  has  information  to  transmit.  The  terminal 
receiving  this  signal  is  not  required  to  take 
any  action  if  this  signal  is  detected. 

3.2.11  Response  session  change  control  positive  (RSCCP) 

3.2.11.1  The  RSCCP  indicates  to  the  sender  of  the 
CSCC  that  the  sink  terminal  intends  to  enter  the 
session  sending  state. 

3.3  Session  procedures 

3.3.1  Session  modes  of  operation 

3. 3. 1.1  The  following  provisions  concern  the 
two-way  alternate  (TWA)  mode  of  session  operation: - 

a)  The  basic  Teletex  protocol  provides  the  capa¬ 
bility  of  TWA  mode; 

b)  At  session  initiation  the  sender  of  the  CSS 
is  defined  as  being  the  current  source  of  any 
text  information  and  is  therefore  the  source 
terminal ; 

c)  The  CSCC  exchanges  the  source/sink  relation¬ 
ship  between  the  two  terminals.  The  CSCC  command 
should  only  be  invoked  outside  document  boundaries; 

d)  Only  the  terminal  that  is  currently  the 
source  terminal  may  send  the  CSCC; 

e)  There  is  no  requirement  for  sending  text  in¬ 
formation  prior  to  sending  a  CSCC. 

f)  When  the  called  terminal  has  finished  trans¬ 
mitting  text  it  shall  hand  back  the  right  of 
sending  text  to  the  calling  terminal.  Only  the 
calling  terminal  is  allowed  to  send  CSE. 

3. 3. 1.2  The  following  provisions  concern  the 
one-way  communication  (OWC)  mode  of  sesion 
operation: - 
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a)  The  CWC  mode  is  achieved  by  the  CSS  sender's 
not  issuing  a  CSCC; 

b)  There  is  no  requirement  to  send  text  infor¬ 
mation; 

c)  This  mode  is  a  subset  of  TWA. 

3.3.2  Rules  for  session  elements  of  procedure 

3. 3. 2.1  Only  the  terminal  that  has  established 
the  transport  connection  (the  "calling"  terminal) 
shall  send  CSS. 

3. 3. 2. 2  It  is  the  responsibility  of  the  sender 
of  CSS  to  examine  the  parameters  of  RSSP  and  to 
determine  whether  the  session  should  continue. 

If  it  is  not  to  be  continued,  the  session  shall 
be  ended  normally  (by  CSE). 

3. 3. 2. 3  In  continuing  the  session,  neither  ter¬ 
minal  is  permitted  to  use  any  procedure  or  to 
send  any  information  that  does  not  comply  with 
the  receiving  capabilities  indicated  by  the 
session  partner,  in  the  Service  Identifier  and 
Non-Basic  Terminal  Capabilities  Parameters  of  the 
CSS/RSSP  exchange  at  session  initiation  and/or 
by  the  parameters  of  CDCL/RDCLP  exchange. 

3. 3. 2. 4  In  the  TWA  or  OWC  mode  only  the  sender 
of  CSS  may  send  CSE  when  he  is  the  current  source. 

3. 3. 2. 5  In  the  TWA  mode,  the  recipient  of  both 
CSS  and  CSCC  must  terminate  his  period  as  source 
by  sending  CSCC. 

3. 3. 2. 6  After  having  sent  CSA  the  sender  may 
clear  the  connection.  In  all  cases  the  connection 
must  be  cleared  when  the  inactivity  timer  has 
expired. 

3. 3. 2. 7  The  parameter  value  "window  si2e"  is  not 
mandatory  and  may  have  a  value  in  the  range  of  1 

to  255.  If  the  parameter  is  indicated  and  accepted, 
the  sendor  of  CSS  must  take  during  the  session  the 
smaller  window  size  exchanged. 

3. 3. 2. 8  Figure  1/S.d  is  a  state  transition  dia¬ 
gram  for  TWA  and  owe  modes.  The  "change  control" 
commands  (marked  with  an  asterisk  in  the  diagram) 
do  not  apply  to  the  OWC  mode.  The  general  de¬ 
scription  and  rules  of  operation  for  state  diagrams 
may  be  found  at  Annex  E. 
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3. 3.2 .7  The  parameter  value  "window  size"  is  not 
mandatory.  The  default  value  is  three.  If  the 
parameter  is  indicated  and  accepted,  the  sender 
of  CSS  must  take  during  the  session  the  smaller 
window  size  exchanged. 

3. 3. 2. 8  Figure  1/S.d  is  a  state  transition  dia¬ 
gram  for  TWA  and  owe  session  modes.  The  "change 
control"  commands  (marked  with  an  asterisk  in  the 
diagram)  do  not  apply  to  the  owe  mode.  The  gene¬ 
ral  description  and  rules  of  operation  for  state 
diagrams  may  be  found  at  Annex  E. 
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3.4  Document  commands,  responses  and  parameters 

a  giinrma r-y  of  daeumeflt  commands  and  responses , 

see  Table  2/S.d.) 

3.4.1  command  document  start  (CDS) 

3. 4. 1.1  The  CDS  indicates  the  start  of  a  docu¬ 
ment  (delivery  unit)  to  tbe  receiver  of  this 
command.  It  also  indicates  the  start  of  the  first 
page  (commitment  unit).  (For  the  definition  of 
delivery  and  commitment  units,  see  Annex  B.) 

3. 4. 1.2  Command  parameters  are:- 

a)  service  interworking  identifier  -  not  man¬ 
datory  field; 

Note:  When  communicating  with  a  conversion  fa¬ 
cility  an  identifier  may  be  required  for: 

a)  Teletex/telex  interworking  -  the 
identifier  will  indicate  that  the  docu¬ 
ment  s)  has  been  prepared  in  accordance 
with  the  rules  given  in  Recommendation 
F.x; 

b)  Teletex/Videotex  interworking  -  for 
further  study; 

c)  Teletex/ facsimile  interworking  -  for 
further  study. 

b)  document  type  identifier  -  not  a  mandatory 
field,  absence  of  this  parameter  indicates  a 
normal  document  (for  a  description  of  types  of 
document,  see  Annex  F); 

c)  document  reference  number  (see  point  4.2.8); 

d)  indication  of  required  terminal  capability 
(standardized  or  private  use)  -  not  a  mandatory 
field,  however,  this  parameter  must  be  used  if 
standardized  optional  terminal  capabilities  are 
required  for  the  document; 

e)  private  use  parameters  (not  mandatory)  - 
definition  of  such  parameters  is  not  stnadardized. 

3. 4. 1.3  There  is  no  response  to  CDS  except  in  the 
case  of  an  error,  for  which  RDGR  is  used. 
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3.4.2  Response  document  general  reject  (RDGR) 

3. 4. 2.1  The  RDGR  may  be  used  by  the  sink  to  in¬ 
dicate  the  source  that  procedural  error  has 

oc cured  and  that  resynchronization  is  requested. 

The  bit  pattern  of  the  command  or  response  up  to 
and  including  the  error  shall  be  returned  to  the 
source.  Only  the  first  detected  error  within  a 
command  or  response  must  be  processed  by  this 
method. 

3. 4. 2. 2  The  response  parameter  is  the  bit  pattern 
required  by  point  3. 4. 2.1. 

3. 4. 2. 3  It  is  the  responsibility  of  the  terminal 
receiving  an  RDGR  response  to  take  appropriate 
action. 

Note:  Use  of  RDGR  for  other  kinds  of  errors  is 
for  further  study. 

3.4.3  Command  document  continue  ( CDC ) 

3. 4. 3.1  The  CDC  indicates  to  the  receiver  of  this 
command  the  continuation  of  transmission  of  a  doc¬ 
ument  (delivery  unit)  that  has  previously  been  par¬ 
tially  transmitted.  There  is  no  response  to  CDS 
except  in  the  case  of  an  error,  for  which  RDGR 

is  used. 

3. 4. 3. 2  Command  parameters  are : - 

a)  Document  linking  information,  in  order  to 
identify  the  previous  transmission  of  the  partial 
document ,  incl uding : 

-  the  checkpoint  reference  number  (see  point  4.2.6) 
from  which  the  transmission  is  being  continued; 

-  the  document  reference  number,  which  shall  be 
the  same  as  the  document  reference  number  in 
the  CDS; 

-  the  session  reference  information  identifying 
the  session  in  which  the  first  part  of  the 
document  was  sent; 

Note:  If  several  continuation  are  required  to 
complete  transmission  of  a  document,  all  are 
linked  to  the  partial  transmission  in  which  the 
CDS  was  used.  The  sequence  of  checkpoint  ref¬ 
erence  numbers  is  then  used  to  identify  the  cor¬ 
rect  sequencing  for  linking  and  all  such  contin¬ 
uations  shall  be  transmitted  in  this  sequence. 
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It  is  the  responsibility  of  the  receiving  ter¬ 
minal  to  discard  any  text  information  that  has 
been  duplicated  in  the  process  of  continuation 
of  an  interrupted  transmission. 

b)  service  interworking  identifier  -  not  a 
mandatory  field  (see  the  note  under  3. 4. 1.2  a) 
for  CDS); 

c)  document  type  identifier  -  not  a  mandatory 
field,  absence  of  this  parameter  indicates  a 
normal  document  (for  a  description  of  the  types 
of  document,  see  Annex  F); 

d)  document  reference  number  (of  the  current 
session)  -  see  point  4.2.3; 

e)  optionally,  any  other  parameter  field(s)  that 
appeared  in  the  CDS  command  at  the  start  of  the 
document  may  be  repeated  as  parameters  in  CDC. 

3. 4. 3. 3  There  is  no  response  to  CDC  except  in  the 
case  of  an  error,  for  which  RDGR  is  used. 

3.4.4  Command  document  capability  list  ( CDCL ) 

3. 4. 4.1  The  CDCL  initiates  an  exchange  of  in¬ 
formation  to  enable  a  check  of  the  terminal 
capabilities  (both  standardized  and  private  use). 

The  command  shall  include  a  list  of  receiving 
capabilities  that  may  be  needed  at  the  receiver 
by  the  sender  of  this  command. 

3. 4. 4. 2  The  command  may  also  be  used  to  in¬ 
vestigate  the  storage  capability  of  the  remote 
terminal.  The  required  amount  of  storage  (given 
in  kilo-octets)  is  indicated  in  a  parameter  of 
the  command  in  this  case. 

Note:  Other  mechanisms  for  storage  are  for 
further  study. 

3. 4. 4. 3  Command  parameters  are  the  list  of  re¬ 
ceiving  capabilities  and  the  required  amount  of 
storage. 

3. 4. 4. 4  The  CDCL  command  should  only  be  invoked 
outside  document  boundaries . 

3.4.5  Response  document  capability  list-positive  (RDCLP ) 

3. 4. 5.1  The  RDCLP  acknowledges  the  CDCL  and  con¬ 
tains  one  of  the  following  three  parameters 

a)  Confirmation  that  all  the  requested  capabilities 
are  available  at  the  receiver; 

I  ^ 


b)  A  list  of  the  requested  capabilities  that  are 
available  at  the  receiver; 

c)  A  complete  list  of  non-basic  receiving  capa¬ 
bilities. 

3. 4. 5. 2  If  the  CDCL  is  used  for  memory  negotia¬ 
tion,  one  of  the  following  parameters  shall  also 
be  included :- 

a)  confiramtion  that  the  amount  of  memory  re¬ 
quested  is  available  and  has  been  reserved; 

b)  indication  of  the  available  (and  reserved) 
amount  of  memory  (in  kilo-octets); 

c)  indication  that  the  available  memory  cannot 
be  estimated; 

d)  indication  that  the  requested  memory  capacity 
cannot  now  be  reserved. 

3.4.6  Command  document  end  ( CDE ) 

3. 4. 6.1  The  CDE  shall  be  used  to  indicate  to  the 
receiver  of  this  command  the  end  of  a  document 
delivery  unit.  It  also  represents  the  final 
checkpoint  to  which  a  response  shall  be  made. 

3. 4. 6. 2  The  command  parameter  is  the  checkpoint 
reference  number. 

3. 4. 6. 3  The  RDPBN  shall  be  used  as  the  negative 
response  to  the  checkpoint  in  CDE. 

3.4.7  Response  document  end  positive  ( RDEP ) 

3. 4. 7.1  The  RDEP  gives  a  positive  acknowledgement 
to  the  last  checkpoint  (commitment  unit).  In  the 
basic  Teletex  service  this  is  the  last  page  ref¬ 
erence  number. 

3. 4. 7. 2  The  RDEP  shall  also  indicate  that  the 
receiver : - 

a)  has  not  detected  any  error; 

b)  accepts  responsibility  for  the  received  docu¬ 
ment  (delivery  unit). 

c)  is  ready  to  receive  a  new  CDS  or  CDC. 


3. 4. 7. 3  The  RDEP  shall  include  as  a  parameter  the 
checkpoint  reference  number  of  the  CDE. 

3. 4. 7. 4  After  sending  RDEP  there  is  no  further 
means  within  these  control  procedures  for  error 
recovery  for  that  document. 

3.4.8  Command  document  discard  ( CDD ) 

3 . 4 . 8 . 1  The  CDD  shall  be  used  to  indicate  to  the 
receiver  of  this  command  the  abnormal  ending  of 

a  document  and  that  the  receiver  of  the  command 
is  not  held  responsible  for  the  part  of  the  docu¬ 
ment  received  so  far.  Therefore,  as  a  local 
function  outside  these  control  procedures,  the 
receiver  can  delete  the  part  of  the  text  received. 

Note:  The  receiving  terminal  may  discard  the 
document  from  its  memory  and/or  indicate  to  the 
operator  that  this  part  of  the  document  has  no 
value . 

3 . 4 . 8 . 2  The  reason  for  sending  a  CDD  command  may 
be  given  as  a  CDD  parameter.  If  used  only  one  of 
the  following  reasons  shall  be  indicated :- 

a)  local  terminal  error; 

b)  unrecoverable  procedural  error; 

c)  reason  not  defined. 

3. 4. 8. 3  The  CDD  may  only  be  used  to  terminate 
the  current  document,  instead  of  using  CDE  or 
CDR.  It  cannot  be  used  after  a  CDR  has  been  sent; 

3. 4. 8. 4  The  receiver  of  a  CDD  is  allowed  to 
delete  the  received  part  of  the  document,  but 
has  no  obligation  to  do  so.  If  the  text  is  not 
deleted,  the  operator  shall  be  informed. 

3.4.9  Response  document  discard  positive  ( RDDP ) 

3. 4. 9.1  The  RDDP  acknowledges  the  CDD  and  indi¬ 
cates  that  the  receiver  of  the  command  is  ready 

to  receive  a  new  CDS  or  CDC.  No  negative  response 
is  allowed. 

3.4.10  Command  document  resynchronization  (CDR) 

3.4.10.1  The  CDR  shall  be  used  by  the  source  to 
indicate  to  the  sink  the  point  of  resynchroniza¬ 
tion.  If  used  within  a  document  it  shall  abnor¬ 
mally  end  that  document. 


3.4.10.2  The  reason  for  an  abnormal  ending  of  a 
document  may  be  given  as  a  CDR  parameter.  If  used, 
only  one  of  the  following  reasons  may  be  given. 

a)  local  terminal  error; 

b)  unrecoverable  procedural  error; 

c)  reason  not  defined. 

3.4.10.3  If,  during  the  transmission  of  a  docu¬ 
ment,  there  is  an  interruption  of  the  transport 
connection  or  session  such  that  another  call 
and/or  session  establishement  is  needed,  the 
following  rules  apply: - 

a)  the  receiving  terminal  shall  treat  the  failure 
as  if  a  CDR  had  been  received  and  an  RDRP,  had 
been  sent; 

b)  the  sending  terminal  shall  treat  the  failure 
as  if  a  CDR  had  been  sent  and  a  RDRP  had  been 
received. 

3.4.11  Response  document  resynchronization  positive  (RDRP) 

3.4.11.1  The  RDRP  is  sent  by  the  receiver  of  a 
CDR  as  a  positive  acknowledgement  of  the  command . 

3.4.11.2  If  RDRP  is  used  within  a  document,  it 
confirms  to  the  sender  of  a  CDR  that  the  sender 
of  RDRP  has  already  accepted  responsibility  for 
the  received  document  (up  to  the  last  checkpoint 
for  which  a  positive  acknowledgement  has  been 
sent) .  It  does  not  indicate  the  possibility  of 
the  receiver  of  the  command's  performing  linking 
of  the  following  parts  of  the  interrupted  document 
(delivery  unit). 

3.4.11.3  The  control  procedures  provide  a  means 
for  resuming  transmission  of  an  interrupted  docu¬ 
ment. 

3.4.11.4  The  linking  of  the  parts  of  an  inter¬ 
rupted  document  is  a  local  operation  at  the  re¬ 
ceiver  and  is  therefore  not  within  the  responsi¬ 
bility  of  the  control  procedures.  Thus  these 
procedures  cannot  guarantee  that  this  linking 
of  parts  of  a  document  will  be  effected. 
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3.4.12  Command  document  user  information  ( CDUI ) 

3.4.12.1  The  CDUI  indicates  to  the  receiver  of 
this  command  that  the  associated  information  is 
to  be  interpreted  as  the  user  text  information 
field  being  conveyed  by  the  Teletex  service. 

3.4.12.2  The  basic  Teletex  service  does  not 
require  any  parameter  for  CDUI.  The  procedure 
provides  means  for  adding  paramters.  Any  such 
need  is  for  further  study. 

3.4.13  Command  document  page  boundary  ( CDPB ) 

3.4.13.1  The  CDPB  indicates  to  the  receiver 
the  boundary  between  pages.  It  also  indicates 
a  checkpoint  for  error  recovery  purposes  (see 
section  4).  CDPB  invites  the  sink  to  accept: 
responsibility  for  the  previously  received  page 
(page  commitment  unit-see  Annex  B). 

3.4.13.2  The  CDPB  command  parameter  is  the  check¬ 
point  reference  number,  which,  in  the  basic  Tele¬ 
tex  service,  is  the  page  reference  number. 

3.4.14  Response  document  page  boundary  positive  (RDPBP) 

3.4.14.1  This  response  shall  be  used  to  indicate 
that  the  receiver  accepts  responsibility  for  that 
page  (acknowledgement  of  commitment  unit). 

3.4.14.2  Response  parameters  are : 

a)  This  mandatory  parameter  gives  the  checkpoint 
reference  number  (see  3.4.13.2  above); 

b)  This  mandatory  parameter  indicates  that  the 
ability  of  the  receiving  terminal  to  continue 
to  accept  traffic  is  jeopardized  (e.g.  memory 
threshold  reached). 

3.4.15  Response  document  page  boundary  negative  ( RDPBN ) 

3.4.15.1  The  response  shall  be  used  to  indicate 
that  the  receiver  does  not  accept  the  responsi¬ 
bility  for  that  page  (commitment  unit),  for 
example  due  to  a  detected  error  or  other  failure. 

3.4.15.2  The  value  I  the  mandatory  parameter 
giving  the  reason  for  a  negative  response  should 
be  one  of  the  following: 

a )  memo  ry  o ve  r  f 1 ow ; 

b)  sequence  error; 


c)  local  terminal  error; 

d)  unrecoverable  procedural  error; 

e)  No  specific  reason  stated.  (Used  for  reasons 
other  than  those  listed.) 

3.1  General  rules  for  document  elements  of  procedure 

3.5.1  When  a  document  has  been  either  started  by  CDS 
or  continued  by  CDC,  it  must  be  terminated  by  either 
CDE,  CDR  or  CDD  prior  to  sending  the  next  CDS  or  CDC. 

3.5.2  The  following  rules  relate  to  the  CDS  and  CDC 
parameters : - 

a)  the  service  interworking  parameter  may  be  used  to 
indicate  that  the  document  is  suitable  for  interworking; 
however,  use  of  this  parameter  is  mandatory  in  the  case 
of  service  interworking; 

b)  absence  of  the  document  type  identifier  indicates 
that  the  associated  document  is  a  normal  text  document. 

3.5.3  No  negative  response  to  CDS  or  CDC  may  be  sent 
after  the  sending  of  a  positive  response  to  any  check¬ 
point  within  that  document. 

3.5.4  No  negative  response  to  CDD  or  CDR  is  allowed 
except  for  error  conditions  where  RDGR  is  allowed. 

3.5.5  With  regard  to  the  responses  to  CDPB  ( RDPBP  or 
RDPBN ) ,  the  receiver  may  reject  reception  for  a  detected 
error,  but  the  receiver  is  not  obligated  to  monitor  for 
errors  in  the  document.  Once  a  page  (commitment  unit) 
has  been  positively  acknowledged,  any  error  recovery 
for  the  subsequent  detection  of  an  error  is  beyond 

the  scope  of  these  control  procedures. 

3 . 6  Rules  for  document  state  diagrams  in  the  basic 
Teletex  service 

3.6.1  General 

3. 6. 1.1  The  rules  common  to  all  state  diagrams 
are  given  in  Annex  E. 

3. 6. 1.2  For  any  error  a  terminal  is  permitted 
to  send  CSA.  If  this  procedure  is  not  used,  the 
following  rules  shall  apply. 

Rules  for  the  sending  protocol  (See  Figure  2/S.d) 

3. 6. 2.1  Any  command  or  response  received  in 
state  1,  1  and  3  shall  cause  an  abnormal  end  of 
the  session  and  sending  of  CSA. 
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3. 6. 2. 2  Reception  of  any  command  or  response 
except  RDPBP  in  states  2-8,  10  and  11  (or 
RDEP  in  state  9)  shall  cause  CDR  or  CDD  to  be 
sent. 

3. 6. 2. 3  Reception  of  any  command  or  response 
except  RDCLP  in  state  14  shall  cause  CDR  to  be 
sent. 

3. 6. 2. 4  In  state  13  receipt  of  RDRP  or  RDDP  will 
cause  a  transition  to  state  1.  Any  other  command 
or  response  will  be  discarded. 

3. 6. 2. 5  The  inactivity  timer  started  when  state 
13  is  entered  is  only  reset  when  a  valid  response 
is  received. 


3. 6. 3.1  Reception  of  any  command  or  response 
except  CDS,  CDC,  CDCL  in  state  shall  cause  RDGR 
to  be  sent. 


3. 6. 3. 2  In  state  12  receipt  of  CDR  or  CDD  will 
cause  a  transition  to  state  13.  Any  other  com¬ 
mand  or  response  received  will  be  discarded. 


3. 6. 3. 3  Reception  of  any  command  or  response  not 
allowed  in  the  state  diagram  or  any  invalid  para¬ 
meters  or  paremeter  values  in  state  2  to  11  may 
cause  RDGR  to  be  sent. 


3. 6. 3. 4  The  inactivity  timer  started  when  state 
12  is  entered  is  only  reset  when  a  valid  command 
is  received. 


Figure  2/S.d  -  Document  state  diagram  for  a  window  size  of 
three  (sending  protocol) .  — 
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Figure  3/S.d  -  Document  state  diagram  for  a  window  size  of 
three  (receiving  protocol) . 
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ERROR  RECOVERY  IN  THE  BASIC  TELETEX  SERVICE 
4-1  General  principles 

4.1.1  During  a  session,  each  partner  is  responsible 
for  the  correct  operation  of  the  following: - 

a)  maintenance  of  the  currently  agreed  source/sink 
relationship; 

b)  proper  use  of  the  comm and/response  procedural 
sequences  as  described  in  the  state  diagrams  and 
rules  for  operation  ( see  section  3.6); 

c)  detection  of  any  period  of  inactivity  in  excess 
of  60  s  (indicating,  for  example,  a  failure  or  other 
inability  to  continue  productive  use  of  the  session). 

4.1.2  Upon  detection  of  any  failure  to  maintain  proper 
operation  as  described  in  point  4.1.1.,  use  of  the 
error  recovery  procedures  defined  for  each  state  is 
mandatory;  or,  where  such  error  recovery  procedures 
are  not  specifically  defined,  session  termination 
(abnormal  end)  is  mandatory. 

4.1.3  In  the  event  of  .an  error,  this  control  procedure 
allows  for  repeated  transmission  of  information.  The 
number  of  repetitions  should  be  limited  by  the  sender. 

4.2  Rules  for  checkpointing 

4.2.1  After  an  abnormal  termination  of  a  document, 
for  recovery  in  the  same  session  the  checkpoint 
reference  number  and  the  document  reference  number 
are  required  in  order  to  identify  unambiguously 
the  point  from  which  to  recover. 

4.2.2  A  new  session  (and  call)  has  to  be  initiated 
after  abnormal  termination  of  a  document  where  recovery 
is  to  be  effected  in  a  subsequent  session  or  after  an 
abnormal  termination  and/or  interruption  of  the  call. 
The  information  required  in  order  to  identify  unam¬ 
biguously  the  point  from  which  to  recover  is:- 

a)  the  reference  for  the  interrupted  session; 

b)  the  document  reference  number;  and 

c)  the  checkpoint  reference  number. 

4.2.2  In  the  basic  Teletex  service  a  checkpoint  must 
be  inserted  at  each  page  boundary  using  CDP3. 

4.2.3  If  a  negative  response  is  received  to  a  command 
representing  a  checkpoint,  the  transmission  must  be 
interrupted  by  sending  a  CDR  or  CDD. 


4.2.4  Within  a  document,  a  final  checkpoint  will  be 
represented  by  the  CDE.  Transmission  of  another 
document  is  not  permitted  until  the  response  to  this 
command  has  been  received. 

4.2.5  Mo  other  checkpointing  is  permitted  in  the 
basic  service.  For  other  applications  an  optional 
checkpointing  mechanism  may  be  used,  as  described 
in  Annex  G. 

4.2.6  Each  command  representing  a  checkpoint  shall 
contain  a  parameter  showing  the  reference  number. 

Each  such  command  calls  for  a  response,  which  shall 
contain  a  parameter  showing  the  checkpoint  reference 
number  to  which  that  response  applies. 

4.2.7  Checkpoint  reference  numbers  shall  be  assigned 
as  decimal  digits  starting  from  001  and  sequentially 
incremented  by  one  for  each  successive  checkpoint  within 
a  document. 

4.2.8  Document  reference  numbers  shall  b~  assigned 
as  decimal  digits,  preferably,  but  not  necessarily, 
starting  from  001  and  sequentially  incremented  by 
one  for  each  successive  document.  Document  reference 
numbers  shall  be  assigned  to  all  documents  in  a  session, 
irrespective  of  the  document  type  identifier  or  whether 
CDS  or  CDC  is  used  as  the  initiating  command. 

4.2.9  The  sum  of  the  number  of  digits  contained  in 
the  checkpoint  reference  number  and  the  document 
reference  number  shall  not  exceed  six,  to  permit 
printing  in  the  available  space  in  the  Call  Identi¬ 
fication  Line  as  defined  in  Recommendation  F.x. 

There  is  no  constraint  on  the  maximum  number  of  digits 
in  either  number  as  long  as  this  limitation  is  not 
exceeded. 

4.3  Acknowledgement  window 

4.3.1  In  the  basic  Teletex  service  the  sender  is  pro¬ 
hibited  from  exceeding  an  acknowledgement  window  size 
of  three.  The  maximum  window  size  may  be  negotiated 
during  session  establishment  using  the  CSS  command 
parameters.  (See  paragraph  5.7.3) 

4.3.2  The  sender  is  permitted  to  recover  from  an 
interrupted  transmission  at  only  one  of  two  points :- 

a)  the  sender  may  transmit  the  entire  document, 
cancelling  the  earlier  partial  transmission  of  that 
document; 


b)  the  sender  may  resume,  starting  at  the  point  in 
the  text  of  the  last  checkpoint  for  which  an  acknow¬ 
ledging  response  was  received. 

c)  On  this  basis,  the  receiver  must  be  able  to  resume 
reception  at  any  checkpoint  ranging  from  the  last 
acknowledged  checkpoint  plus  one,  minus  the  window 
size. 


4.3.3  The  window  mechanism  has  been  introduced  in 
order  to  allow  continuous  transmission  of  documents. 

The  window  mechanism  has  been  introduced  in  order 
to  allow  continuous  transmission  of  documents.  The 
window  mechanism  may  also  be  used  by  the  receiving 
terminal  to  resolve  local  time  problems  without 
affecting  the  continuous  transmission . 

The  design  of  a  terminal  should  be  such  that  continuous 
reception  is  possible  in  normal  operation  of  the  term¬ 
inal  with  an  average  page  size  of  1500  octets.  The  use 
of  the  mechanism  should  take  into  account  the  quality  of 
service  of  F.x. 

If  a  transmission  flow  control  mechanism  is  needed, 
it  shall  be  provided  by  the  transport  service. 

CODING 


5 . 1  Definition. of  terms  used  in  coding 

5.1.1  A  Command  Identifier  (Cl)  or  Response  Identifier 
(RI)  is  the  heading  information  that  identifies  the 
command  or  response  concerned. 

5.1.2  A  Length  Indicator  (LI)  represents  the  length 
in  octets  of  an  associated,  field  or  group  of  fields. 

5.1.3  A  Parameter  Identifier  (PI)  indicates  the  type 
of  information  contained  in  an  associated  field  or 
group  of  fields. 

5.1.4  A  Parameter  Group  Identifier  (PGI)  is  a  special 
case  of  a  PI,  which  indicates  that  the  associated  field 
consists  entirely  of  a  group  of  parameters,  each 
identified  by  a  PI. 

5.1.5  A  Parameter  Value  (PV)  is  the  information 
that  represents  the  value  of  the  parameter  identifed 
by  either  a  PI  or  PGI. 

5.1.6  A  "field"  is  either  a  group  of  one  or  more  bits 
within  a  single  octet  or  a  group  of  one  or  more  octets, 
used  to  represent  a  particular  set  of  information. 
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5.2 


Principles  of  coding 


5.2.1  The  coding  of  session  commands  and  parameters 
is  independent  of  the  coding  of  document  commands  and 
parameters  and  vice  versa. 

5.2.2  Binary  field  encoding  principles  have  been 
used  to  allocate  bit  patterns  for  the  Cl,  Rl,  PGI 
and  PI. 


5.2.3  The  first  section  of  a  session  or  document 
field  consists  of  either  a  Cl  or  an  Rl.  Each  Cl  or 
RI  is  always  immediately  followed  by  an  LI. 

5.2.4  The  value  of  an  LI  is  a  binary  number  that 
represents  the  total  length  of  the  immediately  fol¬ 
lowing  parameter  field(s)  in  octets.  The  value  of 
the  LI  does  not  include  either  itself  or  any  subse¬ 
quent  user  information. 

5.2.5  If  a  parameter  field  indicated  by  a  PGI  appears 
within  a  parameter  field  initiated  by  a  PGI,  the  PV 
field  of  the  "nested"  PGI  field  may  not  extend  beyond 
the  end  of  the  PV  of  the  enclosing  PGI  field. 

5.2.6  To  decode  Cl,  RI,  PGI  and  PI,  all  the  bits  of 
the  identifier  must  be  considered. 

5.2.7  The  format  of  a  paramter  field  initiated  by  a 
PGI  is  the  same  as  the  format  of  such  a  field  initiated 
by  a  PI  except  that  the  entire  PV  field  consists  of  a 
sequence  of  one  or  more  parameter  fields,  each  of  which 
is  initiated  by  either  PI  or  PGI. 

5.2.8  Figures  4,  5  and  6/S.d  illustrate  the  coding 
principles . 
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Motes:  1.  Present  only  if  LI  f  0 

2.  Present  only  after  user  information  commands 
(or  response) 

3.  See  point  5.2.4 

Figure  4/S.d  -  Illustration  of  the  relationship  between  session 
and  document  commands 
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Notes:  In  every  case  the  Cl  can  be  replaced  by  an  RI. 

Any  PI  or  PGI  may  be  omitted  when  it  is  not  used  for  conveying 
information  (i.e.  parameter  values).  Pis  and  PG Is  within  the 
same  nesting  level  are  put  in  order  of  increasing  binary  value. 

Figure  5/S.d  -  Examples  of  command  structure 


Note:  This  figure  may  need  further  study 

Figure  6/S.d  -  Allowable  sequences  of  units  within 
a  command  or  response 

5.3  Coding  of  length  indicators 

5.3.1  The  value  of  an  LI  is  a  binary  number  that 
represents  the  total  length  in  octets  of  the  imme¬ 
diately  following  Cl,  Ri,  PI  and/or  PCI  fields.  The 
value  of  the  LI  does  not  include  either  itself  or 
any  subsequent  user  information,  as  noted  in  5.2.4 
above. 

5.3.2  The  basic  LI  consists  of  a  single  octet  with 

a  maximum  value  of  254  in  decimal  (i.e.,  a  binary  value 
■of  1  1  1  1  1  1  1  01, 

5.3.3  If  the  first  octet  of  the  LI  is  255  decimal 
(i.e.,  a  binary  value  of  11111111),  this 
indicates  that  the  value  of  the  LI  is  contained  in 
the  next  two  following  octets  allowing  a  maximum 
value  of  65535  octets. 

5.3.4  within  any  octet,  the  highest  order  bit  is  bit 

8  with  the  remaining  bits  assigned  in  descending  order. 
Where  the  length  value  is  represented  in  two  octets, 
the  first  contains  the  higher  order  bits. 


C- 31 


V 


5.4  Coding  of  Cl  and  RI  for  session  elements 

5.4.1  The  coding  of  Cl  and  RI  for  session  commands 
and  responses  is  shown  in  Table  3/S.d. 


Table  3/S.d  -  Cl  and  RI  for  session  elements 


Command/Response 

8 

7 

Bit  Number 
6  5  4 

3 

2 

1 

CSS 

0 

0 

0 

0 

1 

1 

0 

1 

CSE 

0 

0 

0 

0 

1 

0 

0 

1 

CSA 

0 

0 

0 

1 

1 

0 

0 

1 

CSCC 

0 

0 

0 

1 

0 

1 

0 

1 

CSUI 

0 

0 

0 

0 

0 

0 

0 

1 

RSSF 

0 

0 

0 

0 

1 

1 

1 

0 

RSSN 

0 

0 

0 

0 

1 

1 

0 

0 

RSEP 

0 

0 

0 

0 

1 

0 

1 

0 

RSAP 

0 

0 

0 

1 

1 

0 

1 

0 

RSCCP 

0 

0 

0 

1 

0 

1 

1 

0 

RSUI 

0 

0 

0 

0 

0 

0 

1 

0 

CSTW 

0 

0 

0 

1 

1 

1 

0 

1 

RSTWP 

0 

0 

0 

1 

1 

1 

1 

0 

RSTWN 

0 

0 

0 

1 

1 

1 

0 

0 

Private  use 

1 

1 

1 

1 

X 

X 

X 

X  ! 

5.4.2  Apart  from  private  use,  the  codes  of  the  com¬ 
mands  and  responses  in  Table  3/S.d  are  assigned  in 
such  a  way  that  the  bits  may  be  interpreted  as  follows 


Bit  1 
2 
3 

4,5 


6,7,8 


1  =  Command  0  =  Response 

1  =  positive  0  =  negative  (response) 

1  =  initiate  0  =  stop  (for  most  commands) 

1  1  Session 

1  0  Session 

0  1  Interaction 

0  0  Session  user 

Set  to  zero  and  reserved  for  extension. 


Note;  If  possible,  this  bit  coding  structure  should 
be  followed  in  making  future  code  assignments,  but 
this  is  not  mandatory  if  the  number  of  available  code 
combinations  is  insufficient.  Therefore,  it  is  not 
intended  as  a  guide  for  implementation. 


5.4.3  One  or  more  of  the  non-allocated  values  are 
to  be  reserved  for  future  extension.  The  method 
of  future  extension  is  for  further  study. 


5.5  Coding  of  Cl  and  RI  for  document  elements 

5.5.1  The  coding  of  Cl  and  RI  for  document  commands 
and  responses  is  shown  in  Tables  4  and  5/S.d  respect¬ 
ively. 


i 


5.5.2  Apart  from  private  use,  the  codes  of  the  commands 
and  responses  in  Tables  4  and  5/S.d  are  assigned  in 
such  a  way  that  the  bits  may  be  interepreted  as  follows: 


Bit 


1 

2 

3 


4,5,6 


1 

1 

1 

1 

1 

0 

0 

0 

0 


Command 

positive 

initiate 


0  0 
1  1 
1  0 
0  1 
0  0 


10  1 


0  =  Response 

0  =  negative  (for  response  ) 

0  =  stop  ( for  most  command- ) 

Document/Delivery  unit 
(Reserved) 

Page  (commitment  unit) 

Reserved 

(Reserved  for  recovery  unit) 
Text 


7,8  Set  to  zero  and  reserved  for  future  extension. 


5.5.3  See  points  5.4.2  and  5.4.3  above. 


5.6  Coding  of  PGIs  and  Pis 

5.6.1  The  coding  of  PGIs  and  Pis  for  session  commands 
and  responses  is  shown  in  Table  6/S.d.  The  coding  of 
the  PGIs  and  Pis  for  document  commands  and  responses 
is  shown  in  Table  7/S.d. 


5.6.2  Tables  8  and  9/S.d  list  the  PGIs  and  Pis  for 
each  command  and  response  for  the  session  and  document 
elements  of  procedure  together  with  an  indication  of 
whether  the  PGIs  and  Pis  concerned  are  mandatory  or 
not 


5.6.3  Where  a  PI  is  allocated  to  a  particular  PGI 
this  is  shown  in  Table  6  or  7/S.d.  Some  Pis  are 
not  allocated  to  a  PGI  and  are  used  as  required. 

Some  Pis  may  be  used  without  preceding  PGI  as  defined 
in  Tables  8  and  9/S.d. 

5.6.4  The  codes  of  these  PGIs  and  Pis  are  assigned 
in  such  a  way  that  the  binary  field  consisting  of 
bits  8,  7  and  6  may  be  interpreted  as  follows: 

bits  876 

000  Session  related 
001  Document  related* 

010  Document  related 

0  1  l*j 

^  ®  Reserved 

1  1  o) 

111  Private  use 

The  binary  field  consisting  of  bits  5  and  4  may  be 
interpreted  as  follows : 

bits  5  4 

0  0  PGI 
0  1  PI 
1  0  PI 
1  1  PI 

The  binary  field  consisting  of  bits  3,  2  and  1  is  used 
to  extend  the  PGIs  when  set  to  000. 

Note:  If  possible,  this  binary  field  coding  structure 

should  be  followed  in  making  future  code  assignments, 
but  this  is  not  mandatory  if  the  number  of  available 
code  combinations  is  insufficient. 

5 . 7  Parameter  values 

5.7.1  Unless  otherwise  specified  the  following  rules 
apply  to  the  fields  containing  parameter  values  (PV): 

a)  where  a  binary  number  is  used  to  represent  a  value, 
the  highest  order  bit  of  each  octet  is  bit  8  with 

the  remaining  bits  assigned  in  descending  order. 

Where  a  binary  value  is  represented  by  more  than  one 
octet,  the  first  octet  contains  the  highest  order 
bits,  with  successive  octets  assigned  in  descending 
order; 

b)  all  bits  reserved  for  future  standardization  shall 
be  set  to  zero; 


*  These  Document  related  PGIs  and  Pis  may  possibly  be  of  use  to 
other  services . 


Note:  Term,  abbrevi.il  inn  for  Terminal 
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5.7.9  Graphic  character  sets  (refer  to  Recommendations 
S.c  and  S.f) 

A  variable  length  field  indicating  the  receiving  capa¬ 
bilities  for  non-basic  standardized  graphic  character 
sets.  Each  such  graphic  character  set  shall  be 
indicated  by  the  sequence  of  characters  used  after 
an  ESCAPE  character  to  designate  that  set,  as  defined 
in  Recommendation  S.f.  Where  more  than  one  such 
character  set  is  to  be  indicated,  a  single  SPACE 
shall  be  used  as  a  separator  between  the  character 
set  indicators. 

5.7.10  Control  character  sets  (refer  to  Recommendations 
S.c  and  §.£) 

A  variable  length  field  indicating  the  receiving  capa¬ 
bility  for  non-basic  standardized  control  character 
sets.  Each  such  control  character  set  shall  be  indi¬ 
cated  by  the  sequence  of  characters  used  after  an 
ESCAPE  character  to  designate  that  set,  as  defined 
in  Recommendation  S.f.  where  more  than  one  such 
character  set  is  to  be  indicated,  a  single  SPACE 
shall  be  used  as  a  separator  between  the  character 
set  indicators. 

5.7.11  Page  formats  (refer  to  Recommendations  S.c 
and  3 . £ ) 

Bit  1  of  the  first  octet  set  to  "one"  shall  indicate 
the  capability  for  use  of  the  optional  maximum  print¬ 
able  area  for  the  ISO  A4  paper  size,  as  defined  in 
Recommendation  F.x.  All  other  bit  values  are  reserved 
for  future  standardization. 

5.7.12  Miscellaneous  terminal  capabilities  (refer 
to  Recommendation  S.f) 

A  variable  length  field  indicating  the  receiving 
capabilities  for  non-basic  standardized  values  of 
character  spacing,  line  spacing  and  graphic  renditions. 
Each  such  function  shall  be  indicated  by  the  sequence 
of  characters  used  after  a  Control  Sequence  Introducer 
( CSI )  for  the  Select  Horizontal  Spacing  (SHS)  for  a 
character  pitch,  for  the  Select  Vertical  Spacing 
( SVS )  for  a  line  pitch  and  for  Select  Graphic  Rendition 
(SGR)  for  a  graphic  rendition.  When  more  than  one 
such  character  sequence  is  to  be  indicated,  a  single 
SPACE  shall  be  used  as  a  separator  between  them. 

5.7.13  Service  identifier 


Bit  1  of  the  first  octet  set  to  "one"  indicates  the 
intention  to  use  the  Teletex  service.  All  other  bit 
values  are  reserved  for  future  standardization. 


i 
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c)  where  a  P V  contains  graphic  characters  that  may 

be  printed  or  displayed,  they  shall  be  in  the  intended 
printing/display  sequence  and  shall  be  coded  as  defined 
in  Recommendation  S.f; 

d)  for  a  PGI  designated  for  extension,  the  Pis  and/ 
or  PGIs  included  in  the  parameter  field  do  not  neces¬ 
sarily  conform  to  the  following  assignments  of  PI 
and  PGI  values. 

5.7.2  Assignment  of  coding  to  the  various  parameter 
values  is  shown  in  the  following  points. 

5.7.3  Identification  of  the  called  terminal 


A  sequence  of  graphic  characters  as  defined  in  Recom¬ 
mendation  F.x. 

5.7.4  Identification  of  the  calling  terminal 

A  sequence  of  graphic  characters  as  defined  in  Recom¬ 
mendation  F.x. 

5.7.5  Date  and  time 

A  sequence  of  graphic  characters  as  defined  in  Recom¬ 
mendation  F.x. 

5.7.6  Additional  session  reference  number 

A  fixed  length  sequence  of  two  decimal  digits  as  coded 
in  Recommendation  S.f. 

5.7.7  Miscellaneous  session  capabilities 

Bit  1  of  the  first  octet  set  to  "one"  indicates  the 
terminal  capability  for  two-way  simultaneous  infor¬ 
mation  transfer. 

Bit  2  of  the  first  octet  set  to  "one"  indicates  the 
terminal  capability  for  session  suspension. 

All  other  bit  values  are  reserved  for  future  stan¬ 
dardization. 

5.7.8  Window  size 

A  binary  number  of  fixed  length  of  one  octet,  with 
a  minimum  value  of  one  and  a  maximum  value  of  255 
in  decimal  (i.e.,  a  binary  value  of  11111111).  The 
default  value  is  three  in  decimal  (i.e.,  a  binary 
value  of  00000011). 


5.7.19  Document  reference  number 


A  sequence  of  decimal  digits  as  coded  in  this  in 
Recommendation. 

5.7.20  Checkpoint  reference  number 

A  sequence  of  decimal  digits  as  coded  in  this  Recom¬ 
mendation  . 

5.7.21  Acceptance  of  CDCL  parameters 

Bit  1  of  the  first  octet  set  to  "one"  indicates  accept¬ 
ance  of  all  non-basic  terminal  capabilities  requested 
by  a  CDCL  command. 

All  other  bit  values  are  reserved  for  future  stand¬ 
ardization. 

Note:  Parameters  b  and  c  of  RDCLP  are  coded  as  non- 
basic  terminal  capabilities . 

5.7.22  Storage  capacity  negotiation 

A  fixed  length  sequence  of  two  octets: 

a)  bit  1  -of  the  first  octet  set  to  "one"  indicates  that 
a  terminal  has  reserved  a  requested  amount  of  storage; 

b)  bit  2  of  the  first  octet  set  to  "one"  indicates 
that  the  binary  field  in  the  following  octet  contains 

a  number  indicating  storage  capacity  requested/reserved 
in  kilo -octets; 

c)  bit  3  of  the  first  octet  set  to  "one"  indicates 
that  a  terminal  cannot  estimate  its  memory  capacity; 

d)  bit  4  of  the  first  octet  set  to  "one"  indicates 
that  a  terminal  cannot  now  reserve  the  requested 
amount  of  memory; 

e)  bits  5  to  8  of  the  first  octet  are  reserved  for 
future  standardization. 

Octet  2  indicates  the  memory  size  available  and/or 
reserved  (the  meaning  is  defined  in  the  first  octet). 

It  shall  be  set  to  11111111  if  bit  3  and/or  4  in 
the  first  octet  is  set  to  "one". 

5.7.23  Receiving  ability  jeopardized 

Bit  1  of  the  first  octet  set  to  "one"  indicates  that 
the  ability  of  the  receiving  terminal  to  continue  to 
accept  user  information  is  jeopardized  (e.g.  memory 
threshold  reached). 

All  other  bits  are  reserved  for  future  standardization. 
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5.7.14 


Reason  (session) 


For  further  study  (RSSN). 

5.7.15  Session  termination  parameter 


Bit  1  of  the  first  octet  set  to  "one"  indicates  that 
the  transport  service  connection  shall  be  cleared 
(default  value).  When  set  to  'O'  it  indicates  that 
the  transport  connection  should  be  cleared. 

Bit  2  of  the  first  octet  set  to  "one"  indicates  a  local 
terminal  error. 

Bit  3  of  the  first  octet  set  to  "one"  indicates  an 
unrecoverable  procedural  error. 

Bit  4  of  the  first  octet  set  to  "one"  indicates  that 
no  reason  is  given. 

All  other  bits  are  reserved  for  future  standardization. 
The  CSE  command  uses  only  bit  1,  all  other  bits  shall 
be  set  to  "zero" . 

5.7.16  Request  session  functions 

In  the  first  octet  the  fgllowing  bit  assignments  are 
defined: 

a)  bit  1  if  set  to  "one"  indicates  request  transmit 
(as  defined  in  this  Recommendation). 

b)  bit  2  if  set  to  "one"  indicates  request  session 
suspension  (as  defined  in  this  Recommendation). 

All  other  bits  are  reserved  for  future  standardization. 

5.7.17  Private  use 

A  set  of  PGI  and  PI  values  is  designated  as  being  for 
private  use.  Other  than  the  PGIs  designated  for 
extensions  and  the  permitted  use  of  private  parameters 
only  with  certain  commands  and  responses,  the  use  of 
these  parameters  is  not  defined. 

5.7.18  Service  interworking  identifier 

Bit  1  of  the  first  octet  set  to  "one"  shall  indicate 
that  the  associated  document  is  suitable  for  forwarding 
via  the  telex  service. 

All  other  bit  values  are  reserved  for  future  stand¬ 
ardization  . 
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Table  8/S.d  -  PGIs  and  Pla  for  session  elements  of  procedure 


5-4-2  SESSION  LEVEL 


SESSION 


Command  or 

Response 

Identifier 


Description 


Session  Reference 

m 

Non-Basic  Session 
Capabilities 

Nm 

Non-Basic  Termi¬ 
nal  Capabilities 

Nm 

Private  Use 

Nm 

Session  Reference 


Non-Basic .Capa¬ 
bilities  Session 


Non-Basic  Termi¬ 
nal  Capabilities 


Private  Use 


For  Further  Study 


Private  Use 


Description 


Terminal  Identifier 
of  the  calling  Term 


Date  and  time 


Window  size 


mmrn 

i Mims 


Service  Identifier 


Session  Termination 


Session  Termination) 


Terminal  Identifier 
of  the  called  term. 


Date  and  time 


Window  Size 


Page  Formats 


VJTi 

[■i'HjH  if4  Pi- 1 4  4H4 


Service  Identifier 


RSEP 


RSAP 


RSCCP 


RSUI 


it  mtm 


Editorial  Note  :  Private  use  has  not  been  restricted  to  only 
those  private  use  fields  indicated  in  the  tables.  Private 
use  may  be  attached  to  any  command  or  response. 

Term,  abbreviation  for  Terminal 


5.7.24  Document  type  identifier 


Annexes 


Absence  of  this  parameter  shall  indicate  a  normal 
text  document.  This  parameter,  if  used,  is  a  binary 
encoded  field  of  fixed  length  of  one  octet,  identifying 
the  document  type  as  follows: 

bit  87654321 
Operator  Document  00000001 

Control  Document  00000010 

Monitor  Document  00000011 

All  other  binary  values  are  reserved  for  future 
standardization . 

5.7.25  Reflect  parameter  value 

This  is  an  arbitrary  length  field  that  contains  the 
bit  pattern  of  the  command  or  response  up  to  and  in-  . 
eluding  the  detected  error. 


5.7.26  Reason  (Document) 


A  binary  encoded  field  indicating  the  reason  for 
failure: 


Bit 


87654321 

00000000 

0000000-1 

00000010 

00000011 

00000100 

00000101 

00000110 


Used  for  reasons  other  than  those  stated 

Memory  overflow 

Transmission  error 

Sequence  error 

Format  error 

Local  terminal  error 

Unrecoverable  procedural  error 


The  absence  of  this  parameter  indicates  that  no  reason 
is  given. 


:  7  (A-G) 


c-HS 


Non-Basic  Terminal 
capabilities 


Private  Ose 


Page  Formats 

Miscellaneous  Term. 
Capabilities. _ 


PI  graphic  character 
sets 

Reflect  parameter 
values _ 


Table  9/S .d  -  PGIs  and  Pis  for  document  elements  of  procedure 


DOCUMENT 


Command 
Identif ie 


Private  Use 


Document  linking 


Only  required 
linking  in  a  c 

session 


Non-basic  Terminal 
Capabilities 

Nm 

Private  Use 

Nm 

Description 


Document  Ref .  No . 


Service  Interworking 
Identifier 


Document  Type  Ident. 


Control  character 


Page  Pormats 


Miscellaneous  Term. 
Capabilities 


Document  reference  N 
checkpoint 
Reference  No. 
Terminal  identifier 
of  the  called  term. 
Terminal  identifier 
of  the  calling  term, 
date  and  time 
additional  session 
ref .  no . 

Service  interworking 
identifier 
Document  type 
identifier 
Document  reference 
(current  session) 
Other  parameters  of 
CDS 


Checkpoint  ref 
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Reason  (Document) 


Checkpoint  ref.  No. 


Storage  capacity 


Control  character 


Page  Pormats 


Miscellaneous  Term. 
Capabilities _ 


PI  graphic  character 

sets 


-  abbreviation  for  Terminal 


Term 


2.2  Modes  of  session:  There  are  three  different  modes: 

a)  One  way  Communication  (OWC).  Customer  information 
is  transferred  in  one  direction  only  during  the  session, 
i.e.  only  one  of  the  terminals  will  have  the  right  to  be 
the  source. 

b)  Two  way  Alternate  (TWA).  Customer  information  is 
transferred  in  both  directions,  but  only  in  one  direction 
at  a  time,  i.e.  the  source/sink  relation  will  be  changed 
one  or  more  times  during  the  session. 

c)  Two  Way  Simultaneous  (TWS).  Customer  information 
is  transferred  in  both  directions  simultaneously,  i.e. 
both  terminals  are  simultaneously  a  source  as  well  as 
a  sink. 

Note:  TWS  mode  is  for  further  study. 

2.3  Basic  session  reference:  The  basic  session  reference 
is  used  to  identify  a  session.  It  consists  of:- 

a)  called  terminal's  identifier; 

b)  calling  terminal's  identifier; 

c)  date  and  time. 

2.4  Expanded  session  reference:  The  expanded  session 
reference  is  used  to  identify  a  session  uniquely.  It 
consists  of  the  mandatory  basic  session  reference  plus 
an  optional  additional  session  reference  number. 

TERMS  SPECIFIC  TO  DOCUMENT  PROCEDURES 

.  \ 

3.1  Document :  A  document  is  a  sequence  of  one  or  more 
pages  intended  by  the  originator  to  be  delivered  to 
the  address(es)  as  a  single  entity  in  the  original 
page  sequence. 

3.2  Teletex  Page:  The  basic  element  of  office  corres- 
pondence  in  the  Teletex  service.  One  A4  (or  A4L 

or  North  American  Standard)  page  or  the  information 
that  may  be  presented  on  it. 

3.3  Check  point:  A  check  point  is  a  numbered  mark  inserted 
by  the  sender  in  the  text  stream  to  provide  a  reference 
point  for  error  recovery. 

3.4  Acknowledgement  windows :  The  maximum  number  or  check 
points  that  a  sender  can  transmit  without  receiving 
an  acknowledgement  from  the  receiver. 
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ANNEX  A 


DEFINITIONS 

Note:  Some  of  the  terms  used  in  this  Recommendation  have 
been  defined  in  ways  that  may  differ  from  the  meanings  of 
similar  terms  in  other  Recommendations . 

1  • 


1.1  Teletex  Terminal:  A  device  that  is  capable  of  trans- 
mitting  and  receiving  Teletex  documents  in  accordance 
with  the  basic  requirements  of  Recommendation  Sc. 

1.2  Teletex  Call :  The  temporary  connection  (or  apparent 
connection  as  perceived  by  the  caller)  of  one  terminal 
to  another  for  the  purpose  of  exchanging  information. 

1.3  Calling  Terminal:  That  terminal  that  initiates  the 
procedures  to  establish  a  call. 

1.4  Called  Terminal:  That  terminal  to  which  a  call  is 
made . 

1.5  Service  interworking:  The  facility  of  sending  and 
receiving  information  between  a  Teletex  terminal  and 
a  terminal  of  another  service,  eg  Telex. 

1.6  Command:  A  command  is  control  information  sent  to 
another  terminal  to  initiate  execution  of  a  specific 
function.  Some  commands  require  a  response. 

1.7  Response :  A  response  is  control  information  sent  by 
the  recipient  of  the  command  to  advise  the  sender  of 
the  command  of  the  action  taken.  Exceptionally,  the 
reaction  to  a  response  may  be  another  response. 

1.8  Source/sink  relationship 

174  Customer  information  is  transferred  from  a  source  to  a  sij 

4.1.2 

2  TERMS  SPECIFIC  TO  SESSION  PROCEDURES 


2.1  Session:  A  session  is  the  interval  during  which  a 
logical,  mutually  agreed  correspondence  between  two 
application/presentation  processes  exists  for  the 
transfer  of  application  and  presentation  related 
information. 


2.2  Commitment  unit  (CU) 


Element  inviting  the  sink  to  take  over  responsibility  for 
the  transmitted  information. 

2.3  Delivery  unit  (DU) 

One  or  more  commitment  units  that  are  to  be  considered  as 
a  single  entity  for  the  purpose  of  synchronization. 

2.4  Interaction  unit  (IU) 

Element  indicating  the  change  of  source  and  sink  of  data. 

USER  STRUCTURE  ELEMENTS 

3 . 1  Document  user  information  block  (DU) 

Smallest  quantity  of  information  preserved  as  one  unit  by 
the  procedure. 

3.2  Page  (P) 

The  unit  of  information  that  may  be  presented  on  one  physical 
page. 

3.3  Document  (D) 

A  sequence  of  one  or  more  pages  intended  to  be  delivered 
as  a  single  unit  in  the  original  page  sequence. 

RULES 


4.1  The  dialogue  elements  are  related  in  accordance  with 
the  following  hiearchy:- 

RU  -  lowest  level  in  the  hierarchy 

CU 

DU 

IU  -  highest  level  in  the  hierarchy 

4.2  Initiation/termination  of  any  unit  in  this  hierarchy 
also  initiates/terminates  all  units  at  lower  levels  of  the 
hierarchy . 


ANNEX  S 
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ELEMENTARY  FUNCTIONS  OF  THE  PROCEDURE 
1  INTRODUCTION 


1.1  The  purpose  of  this  Annex  is  to  provide  a  more  formal 
description  of  the  document  elements  of  procedure.  The 
definition  of  independent  and  elementary  functions  forming 
a  basic  set  of  elements  leads  to:- 

a)  the  description  of  each  element  of  procedure  in  this 
basic  set  is  unambiguous  (open  to  a  single  interpretation) ; 

b)  the  functions  that  are  common  in  two  different  elements 
of  procedure  appear  clearly  in  the  description  of  these 
elements  ( see  Table  1 ) ; 

c)  the  separation  of  the  elements  of  procedure  into 
dialogue  elements  and  elements  concerning  the  structure 
of  the  user  information; 

d)  for  future  elements  of  procedure,  this  basic  set  helps 
to  re-use  the  elements  in  the  basic  set,  which  are  already 
implemented,  in  new  combinations, 

1.2  Sections  2  and  3  below  describe  the  basic  set  of 
elementary  functions.  These  functions  have  been  selected 
such  that : - 

a)  they  are  elementary  (they  cannot  be  subdivided); 

b)  they  are  independent; 

c)  any  element  of  procedure  shall  be  capable  of  being 
described  using  the  basic  set. 

1.3  Only  the  document  elements  of  procedure  have  been 
taken  into  account. 

2  DIALOGUE  ELEMENTS 

2 . 1  Recovery  unit  (RU) 

A  unit  delimited  by  a  recovery  mark  inserted  by  the  sender 
in  the  text  stream  to  provide  a  reference  point  for  resuming 
transmission  after  a  transmission  interruption. 

Note:  The  RU  may  be  used  to  provide  for  different  recovery 
mechanisms .  The  recovery  mark  may  or  may  not  require  an 
•cunovl edging  response  depending  upon  the  recovery  mechanism. 


I 


i 
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*  only  applicable  for  TWA  mode 
**  only  applicable  for  TWS  mode 

Figure  1/Annex  C  -  State  diagram  for  OWC,  TWA  and  TWS 
modes  (error  states) 


Table  1/Annex  ...  -  Analysis  of  document  layer  commands  and  response 

in  terms  of  elementary  functions 


Command 

User  structure 

Dialogue 

CDS 

Start  of  D,  P 

Start  of  DU  (CU,  RU) 

CDE 

End  of  D,  P 

End  of  DU  (CU,  RU)  | 

CDR 

Suspend  D 

Discard  current  P 

End  of  DU  (CU,  RU)  ^ 

CPB 

End  of  P 

End  of  CU  (RU) 

Start  of  P 

Start  of  CU  (RU)  i 

CDUI 

Start  of  DU 

1 

CDC 

Continue  D 

Start  of  P 

Start  of  DU  (CU,  RU) 

CDD 

Discard  D 

End  of  DU  (CU,  RU) 

RDEP 

• 

Ack  XU  (CU,  RU) 

RDPB 

Ack  CU  (RU) 

RDPBN 

- 

Nack  CU  (RU) 

RDRP 

- 

Ack  DU  (CU,  RU) 

RDGR 

End  of  DU  (CU,  RU) 

Positive 

- 

RDCP 

Positive 

- 

Ack  RU 

RDGR 

- 

End  of  DU  (CU,  RU) 

c-z-f 


2.4 


Command  session  suspension  request  (CSUR) 

2.4.1  The  CSUR  can  be  used  by  the  called  terminal 
to  indicate  that  a  halt  in  the  information  flow  is 
needed.  The  calling  terminal  can  then  decide  what 
to  do. 

2.4.2  No  explicit  response  is  required  since  a  sus¬ 
pension  is  implicitly  the  positive  response  and  negative 
response  has  no  meaning.  The  request  shall  be  void  if 
not  acted  upon  within  (period  to  be  defined). 

2.4.3  The  CSUR  parameter  is  an  indication  of  the 
required  duration  for  the  suspension. 

2.5  Command  session  reactivate  (CSR) 

2.5.1  The  CSR  is  sent  when  reactivating  a  suspended 
session. 

2.5.2  The  terminal  that  initiated  the  session  is 
respooisble  for  reactivating  it  before  the  time  that 
was  indicated  in  the  suspension  command  has  expired. 

This  responsibility  does  not  exclude  the  possibility 
of  the  other  terminal's  reactivating  the  session. 

Note:  The  rules  for  reactivation  require  further  study. 

2.5.3  The  parameters  required  for  the  linking  of  the 
reactivated  session  require  further  study. 

2 . 6  Response  session  reactivate  positive  ( RSRP ) 

2.6.1  The  RSRP  indicates  that  the  session  reactivation  i 

is  accepted  and  that  the  communication  can  start.  * 

« 

2.6.2  The  RSRP  parameters  are  for  further  study.  * 

2 . 7  Response  session  reactivate  negative  ( RSRN ) 

2.7.1  The  RSRN  indicates  that  the  session  reactivation 
cannot  be  effected. 

2.7.2  The  RSRN  parameter  shall  indicate  the  reason 
for  the  negative  response  from  amongst  the  following 
(for  further  study) 

a)  the  command  was  used  illegally  (sent  by  the  called 
terminal,  refers  to  a  session  that  is  already  active, 
or  is  sent  before  clearing  or  suspension  of  another 
session) ; 


*2- 


ANNEX  D 


SESSION  SUSPENSION  FACILITY 


Note:  Further  study  required 

1  GENERAL 

1.1  The  session  suspension  facility  is  an  extension  of 
the  basic  Teletex  control  procedure.  For  a  negotiable 
time,  it  gives  the  possibility  of  clearing  the  call  without 
losing  the  logical  relationship  represented  by  the  session. 

2  ELEMENTS  OF  PROCEDURE 


2.1  Command  session  suspend  (CSSU) 

2.1.1  The  CSSU  is  sent  by  the  calling  terminal  when 
a  suspension  of  the  session  is  required.  A  session 
cannot  be  expected  to  exist  after  the  indicated  time 
has  expired  (see  CSR  in  point  2.5  below). 

2.1.2  The  command  parameters  are:- 

a)  the  time  interval  during  which  the  session  may 
be  reactivated  (format  for  study  under  coding); 

b)  an  indication  for  the  release  of  the  transport 
connection. 

2.2  Response  session  suspend  positive  (RSSP) 

2.2.1  The  RSSP  indicates  that  the  suspended  state 

has  been  entered  by  the  called  terminal  in  a  controlled 
way. 

2.3  Response  session  suspend  negative  (RSSUN) 

2.3.1  The  RSSUN  indicates  that  the  session  suspension 
cannot  be  accepted.  The  reason  for  the  rejection  shall 
be  indicated  as  a  parameter. 

2.3.2  The  RSSUN  parameter  indicates  one  of  the  fol¬ 
lowing  reasons  for  rejection: - 

a)  the  CCSU  was  illegally  used  (e.g.  by  a  terminal 
that  is  not  the  paying  terminal),  this  shall  not  be 
regarded  as  an  error  leading  to  clearing; 

b)  a  suspended  session  is  temporarily  not  possible; 

c)  more  than  one  suspended  session  per  terminal  is 
not  possible; 

d)  the  indicated  time  for  the  suspension  is  too  long. 
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CALLING  TERMINAL 


C-Al  i  rn  TERMINAL 


*  This  is  the  state  from  which  the  session  was  suspended  and 
from  which  it  is  to  be  resumed. 

Figure  1/Annex  D  -  Session  state  diagram  for  session  suspend 


b)  the  linking  information  is  not  recognized  (wrong 
terminal  identifier,  wrong  session  identifier,  or 
the  session  has  been  cleared  during  the  suspension 
by  the  called  terminal ) . 

STATE  DIAGRAM 

3.1  Figure  1/Annex  D  is  a  session  state  transition  diagram 
for  the  session  suspension  facililty  (showing  additions  to 
the  session  state  transition  diagram  required  for  the  faci¬ 
lity)  . 


Upon  detection  of  a  failure  to  maintain  proper  operation  as 
described  above,  use  of  error  recovery  procedures  defined  for 
each  state  diagram  is  mandatory,  or  where  such  error  recovery 
procedures  are  not  specifically  defined,  session  termination 
(abnormal  end)  is  mandatory.  This  is  necessary  in  order  to 
avoid  unproductive  use  of  Teletex  facilities,  incurring  un¬ 
necessary  charges  where  the  service  is  not  being  used  effect¬ 
ively,  and  causing  degradation  of  the  service. 

10.  The  purpose  of  the  state  diagrams  is  to  assist  in  defining 
proper  use  of  the  elements  of  procedure,  not  to  define  any 
particular  implementation. 
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ANNEX  E 


GENERAL  DESCRIPTION  AND  RULES  OF  OPERATION  FOR  STATE  DIAGRAMS 

1.  Each  state  diagram  is  in  only  one  state  at  any  time. 

2.  Each  state  is  represented  as  an  ellipse,  which  contains  a 
number  for  reference  and  a  descritpvie  name. 

3.  Permissible  transitions  from  one  state  to  another  acre  shown 
as  connecting  lines  with  an  arrow  indicating  the  permitted  dir¬ 
ection  of  the  state  transition  and  labelled  with  the  even  or 
events  that  cause  that  trams ition. 

4.  Where  a  transition  may  originate  from  any  of  several  states, 
it  may  be  indicated  by  a  broad  arrow  terminating  on  the  des¬ 
cription  state  and  labelled  with  the  permissible  states  of 
origination  and  with  the  even  or  events  that  cause  that  entry 
into  the  estimation  state. 

5.  An  event  is  either  the  sending  (S  -)  or  reception  (R  -)  of 
a  command  or  a  response  or  an  indicated  local  operation. 

6.  Each  state  diagram  has  a  state  named  "idle"  and  numbered 
zero.  This  is  the  initial  or  reset  sate  when  that  state  diagram 
is  inactive. 

7.  Upon  sending  any  command  that  causes  entry  into  a  state 
named  "demand  response1',  the  sending  of  any  additional  commands 
is  not  permitted  until  a  response  is  received.  An  inactivity 
timer  is  started,  and,  if  a  response  is  not  received  prior  to 
expiration  of  that  timeout,  session  termination  either  directly 
if  Command  Session  Abort  <CSA)  was  sent  or  by  sending  CSA  is 
mandatory . 

8.  The  effect  of  each  event  that  causes  a  state  transition 
must  be  completed  prior  to  consideration  of  a  subsequent  event. 

9.  During  a  session,  each  session  partner  has  a  responsibility 
for  monitoring  for  proper  operation  as  follows :- 

a)  maintenance  of  the  currently  agreed  source/slnk  relationship; 

b)  proper  use  of  command/response  procedural  sequences  as 
described  in  the  state  diagrams  and  the  rules  for  their 
operation; 

c)  monitoring  for  a  period  of  inactivity  (e.g.  indicating  a 
failure  or  other  inability  to  continue  productive  use  of  the 
session) . 
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4  CONTROL  DOCUMENT  (OPTIONAL) 

4.1  The  control  document  can  be  used  in  communication  with 
intermediate  stor-and-forward  equipment. 

4.2  The  addressing  information  (and  other  control  infor¬ 
mation  required)  can  be  included  as  text  within  such  a 
document.  The  control  document  shall,  except  for  the 
document  type  indication,  follow  the  same  rules  (in  the 
procedure)  as  a  normal  document.  The  use  of  the  control 
document  is  a  national  matter  and  is  outside  the  scope 

of  this  recommendation. 

5  MONITOR  DOCUMENT  (OPTIONAL) 

5.1  The  monitor  document  will  not  be  made  available  to 
the  user.  It  is  intended  to  be  available  for  purposes 
that  can  be  defined  by  each  administration ,  e.g.  for 
maintenance  purposes. 

5.2  The  monitor  document  will  be  handled  by  the  operating 
system  of  the  terminal  and  not  displayed  to  the  operator. 
The  monitor  document  shall,  except  for  the  document  type 
indication,  conform  with  the  same  rules  (in  the  procedure) 
as  a  normal  document. 
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TYPES  OF  DOCUMENT 


1  GENERAL 

1.1  An  indication  of  the  type  of  document  that  is  trans¬ 
ferred  shall  be  given  at  the  start  of  each  document,  if  not 
the  normal  type  of  document  is  used. 

1.2  A  document  type  indication  wil^.  indicate  to  the  oper¬ 
ating  system  of  the  receiving  terminal  that  a  special 
action  is  required  (the  action  is  defined  for  each  type 

of  document) . 

1.3  No  additional  procedure  elements  or  changes  in  state 
transition  diagrams  are  required. 

2  NORMAL  DOCUMENT 

2.1  This  is  the  normal  type  of  document  to  be  used  to 
trams fer  text  in  the  Teletex  service.  The  document  is 
supposed  to  be  immediately  stored.  Presentation  of  the 
text  is  a  local  function  and  is  not  controlled  by  the 
procedure.  The  unit  document  can  in  its  turn  be  divided 
into  a  number  of  pages.  The  subdivision  of  the  text  into 
different  pages  must  be  maintained  in  the  handling  and 
during  the  presentation.  The  same  is  valid  for  the  present¬ 
ation  format  within  the  page. 

2.2  From  the  procedures  point  of  view,  every  Teletex  terminal 
must  be  able  to  handle  this  type  of  document. 

Note:  Where  appropriate  the  rules  for  the  usage  of  optional 
functions  have  to  be  followed. 

3  OPERATOR  DOCUMENT  (OPTIONAL) 

3.1  The  operator  document  represents  a  type  of  priority 
message.  It  can  be  used  in  the  conversational  mode  of 
operation. 

It  is  intended  to  be  presented  immediately  to  the  operator 
(although  the  decision  to  present  it  is  left  to  the  receiving 
operator).  It  may  therefore  be  immediately  indicated  to 
the  operator  that  a  new  operator  document  has  been  received. 
The  operator  document  shall  conform  with  the  same  presentation 
control  functions  and  be  treated  in  the  procedure  as  a  normal 
document.  The  length  of  an  operator  document  is  arbitrary 
but  it  shall  preferably  (due  to  the  application)  not  exceed 
one  page.  Note  that  a  terminal  that  does  not  have  a  special 
dialogue  mode,  can  handle  an  operator  document  as  a  normal 
document . 
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5  RESPONSE  DOCUMENT  RECOVERY  POINT  RESTART  (RDRPR) 


5.1  The  RDRPR  shall  be  used  by  the  sink  to  indicate  to 
the  source  from  which  recovery  point  the  resynchronization 
is  available. 

5.2  The  RDRPR  parameter  is  the  recovery  point  reference 
number . 

5.3  The  recovery  point  reference  number  shall  be  lower 
than  or  equal  to  the  number  indicated  by  the  source  in 
the  RDRPR  command. 
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OPTIONAL  ERROR  RECOVERY  MECHANISM  (l „  4 ini/) 

1  INTRODUCTION 

1.1  Section  4  of  this  Recommendation  describes  the  error 
recovery  mechanism  used  in  the  basic  Teletex  service.  With 
mixed-mode  operation  (e.g.  Teletex  and  facsimile)  or  with 
facsimile  alone,  there  is  a  need  for  another  recovery 
mechanism,  as  described  below,  that  allows  resynchronization 
of  the  source  and  the  sink  within  a  page  (commitment  unit) 
or  a  document  (delivery  unit)  without  ending  the  document 
and  discarding  the  whole  current  page. 

1.2  This  recovery  mechanism  may  also  be  applied,  as  an 
option,  in  the  Teletex  service. 

1.3  The  commands  and  responses,  together  with  their  para¬ 
meters,  required  for  this  optional  recovery  (or  resynchro¬ 
nization)  mechanism  are  described  below. 

2  COMMAND  DOCUMENT  RECOVERY  POINT  (CDRP) 

2.1  The  CDRP  shall  be  used  to  indicate  a  recovery  point 
from  which  the  source  or  the  sink  may  ask  for  a  resyn¬ 
chronization. 

2.2  The  CDRP  parameter  is  the  recovery  point  reference 
number . 

2.3  The  CDRP  command  is  sent  by  the  source  at  arbitrary 
points  in  the  text. 

2.4  The  commands  CDS,  CDC,  CDPB  are  to  be  considered  as  an 
implicit  recovery-point  number  0. 

3  RESPONSE  DOCUMENT  RECOVERY  POINT  NEGATIVE  ( RDRPN ) 

3 . 1  The  RRPN  shall  be  used  by  the  sink  to  resynchronize 
the  source  from  a  recovery  point. 

3.2  The  RRPN  parameter  is  the  recovery  point  reference 
number. 

4  COMMAND  DOCUMENT  RECOVERY  POINT  RESTART  ( CDRPR) 

4.1  The  CDRPR  3hall  be  used  by  the  source  to  resynchronize 
the  sink  from  the  indicated  recovery  point. 

4.2  The  CDRPR  parameter  is  the  recovery  point  reference 
number. 


